Blue Prism Technical Architect common mistakes
Blue Prism Technical Architect · Understand the traps and how to avoid them.
When asked to design a Blue Prism infrastructure for high availability, the candidate proposes a single application server and a single database server without redundancy, and does not address session persistence or load balancing.
Candidates often focus on functional process design and overlook the non-functional requirement of high availability. They may not be familiar with Blue Prism's multi-server architecture or the role of the connection broker and load balancing.
What to do instead
Study the Blue Prism architecture guide: understand that multiple application servers can be deployed behind a load balancer, that the database must be clustered or mirrored, and that session persistence is handled via the database. Practice designing a reference architecture that includes at least two application servers, a highly available SQL Server instance, and appropriate network segmentation.
In a governance scenario, the candidate assigns all ROM roles (e.g., Process Analyst, Developer, Controller, Support) to the same small team without segregation of duties, and fails to define a Centre of Excellence (CoE) structure.
Candidates may treat ROM as a checklist rather than a operating model. They underestimate the importance of role separation for quality and control, and may not have practical experience in setting up a CoE.
What to do instead
Review the Blue Prism ROM documentation: learn the responsibilities of each role and the recommended team structures for different maturity levels. Practice mapping roles to a RACI matrix and designing a CoE that includes representation from IT, business, and risk. Emphasize segregation of duties between development, testing, and production support.
When designing a solution, the candidate creates a single monolithic process that handles all business logic and exception handling, without modularization or reuse of objects.
Candidates often think in terms of end-to-end automation and try to capture everything in one process. They may lack experience with Blue Prism's best practices for process decomposition and object reuse.
What to do instead
Study the Blue Prism solution design principles: separate processes into layers (e.g., process, object, utility), use objects for application interaction, and create reusable components. Practice decomposing a complex scenario into multiple processes and objects with clear interfaces. Emphasize maintainability and scalability.
In Process Studio, the candidate uses the default exception handling block without configuring any recovery logic, and does not set appropriate retry limits or exception types.
Candidates may rely on the built-in exception handling without understanding its behavior. They might not realize that unhandled exceptions cause the process to terminate and that recovery logic must be explicitly designed.
What to do instead
Learn the Blue Prism exception handling framework: understand the difference between system exceptions and business exceptions, how to use the Recover and Resume stages, and how to set retry counts and intervals. Practice designing exception blocks that log errors, attempt recovery, and escalate when necessary. Always include a clean-up stage.
In Object Studio, the candidate uses hard-coded wait times (e.g., 5000 ms) instead of dynamic waits based on application readiness, leading to unreliable automation.
Candidates may not know how to use Blue Prism's wait stages effectively or how to detect application state. They might default to fixed delays as a quick fix.
What to do instead
Study the use of Wait stages with conditions (e.g., checking for element existence or window title) and the use of the Application Modeller to define robust element attributes. Practice creating dynamic waits that poll for specific conditions with timeouts, and avoid fixed delays except as a last resort.
When modelling an application, the candidate uses only the window title and index attributes to identify elements, resulting in fragile automation that breaks when the UI changes slightly.
Candidates may not understand how Blue Prism's Application Modeller works or the importance of selecting stable attributes. They might take the first matching attributes without considering robustness.
What to do instead
Learn the best practices for Application Modeller: use multiple attributes that are stable and unique (e.g., name, class, control type), avoid dynamic attributes like index or position, and use wildcards judiciously. Practice spying elements and testing them under different conditions. Use the Highlight feature to verify element identification.
In data management, the candidate stores sensitive data (e.g., passwords, personal identifiers) in plain text within process variables or environment variables, without encryption or secure storage.
Candidates may not be aware of Blue Prism's credential management features or may prioritize convenience over security. They might not consider compliance requirements.
What to do instead
Study Blue Prism's Credential Manager and the use of environment variables for non-sensitive configuration. Learn how to store credentials securely using the built-in credential store (e.g., Windows Credential Manager or CyberArk integration). Never hard-code credentials in processes or objects. Use data encryption for sensitive data at rest and in transit.
When handling exceptions, the candidate catches all exceptions in a single block and treats them the same way, without distinguishing between business exceptions and system exceptions.
Candidates may not understand the different exception types and their implications. They might use a generic catch-all to simplify development, but this leads to inappropriate handling.
What to do instead
Learn the Blue Prism exception taxonomy: business exceptions (e.g., invalid data) should be handled differently from system exceptions (e.g., application crash). Use separate exception blocks or check the exception type. Design recovery strategies that are appropriate for each type, and ensure business exceptions are logged and reported without retrying.
In deployment, the candidate promotes a process directly from development to production without going through a testing environment, and does not use Blue Prism's release management features (e.g., packages, version control).
Candidates may underestimate the importance of environment promotion and testing. They might not be familiar with Blue Prism's release manager or may lack experience with controlled deployments.
What to do instead
Study the Blue Prism release management lifecycle: development, testing, staging, production. Learn how to use the Release Manager to create packages, compare versions, and deploy to target environments. Always promote through a testing environment and obtain sign-off. Use version control and maintain a deployment log.
When planning for performance and scalability, the candidate ignores the impact of database growth and does not consider archiving strategies, leading to degraded performance over time.
Candidates may focus on immediate process performance and overlook long-term data management. They might not be aware of Blue Prism's data retention policies or the need for regular maintenance.
What to do instead
Learn about Blue Prism's database maintenance: regular index rebuilds, statistics updates, and archiving of old session logs and work queue data. Design a data retention policy and implement archiving processes. Monitor database size and performance metrics to proactively scale resources.