Blue Prism Developer common mistakes
Blue Prism Developer · Understand the traps and how to avoid them.
Building the happy path first and only adding exception handling after the process 'works', so the recovery logic is bolted on and untested.
Candidates treat exception handling as a final polish step rather than a design constraint, and exam scenarios that inject a business exception mid-flow then expose missing recovery paths.
What to do instead
Design each stage with an explicit 'what if this fails' pass before moving on: decide per action whether a failure is recoverable (business exception) or systemic (system exception), and record that decision in stage naming and block structure.
Using a system exception for a foreseeable business condition, such as 'customer record not found', causing the whole case to abort instead of being routed for review.
The two exception types look interchangeable in the palette, and candidates pick whichever is convenient rather than reasoning about whether the process can continue.
What to do instead
Apply the rule: if the process can meaningfully continue or route the item to a work queue for human handling, raise a business exception; reserve system exceptions for environment, application, or unrecoverable failures.
Putting all recovery logic in a single top-level block at the end of the Main Page, leaving intermediate stages unprotected.
Candidates mirror the 'one try/catch' habit from general programming and underestimate how Blue Prism block scoping determines which handler catches an exception.
What to do instead
Place recovery blocks tightly around the stages they protect so the handler knows the exact context, and keep the top-level block as a last resort that logs and terminates the case cleanly.
Writing process logic directly in Object Studio actions, embedding business decisions inside the application layer.
It feels faster to branch on data while the application is already open, and candidates miss the architectural boundary the exam tests.
What to do instead
Keep business objects limited to interacting with the target application and returning data; move all decisions, looping, and routing into Process Studio, and verify each action has a single, reusable purpose.
Spying elements once and reusing them without checking attributes, so the object breaks on the second run or on a different screen state.
Candidates test against a single happy-path screen and do not consider dynamic attributes, window titles, or index-based matching.
What to do instead
After spying, review and prune attributes to the stable, unique minimum, prefer wildcards for volatile values, and test the element against multiple records and screen states before accepting it.
Ignoring wait stages and application readiness, relying on fixed delays to cover slow responses.
Fixed delays appear to work in a demo and candidates confuse 'it passed once' with reliability.
What to do instead
Use wait stages on a specific element or condition with a sensible timeout, and treat timeouts as exceptions to be handled rather than as reasons to lengthen a sleep.
Treating work queue configuration as an afterthought, leaving items with no defined exception status or retry policy.
Candidates focus on the visible process flow and skim the queue settings, which the exam probes through scenarios about item lifecycle.
What to do instead
Learn the item states and how an item moves between them, set exception handling per queue, and be able to explain what happens to a tagged item and when it is retried or marked complete.
Confusing what belongs in Control Room versus what belongs in the process, such as expecting a schedule to handle retry logic.
Scheduling, sessions, and queue management are visually similar in the interface and candidates memorise screens rather than responsibilities.
What to do instead
Separate the concerns explicitly: Control Room owns when and where processes run, sessions, and queue administration; the process owns how an item is processed and recovered. Answer scenario questions by asking which layer owns the decision.
Naming stages and pages vaguely, and leaving dead or commented-out stages in the diagram, making the flow unreadable.
Candidates build iteratively and never do a cleanup pass, and they underestimate how much the exam rewards clarity of design intent.
What to do instead
Adopt a naming convention that states the action and object, delete or clearly mark unused stages, and keep each page focused on one responsibility so the flow reads top to bottom.
Skipping the design step and jumping straight into Process Studio, producing a flow with duplicated logic and no clear exception or data-handling model.
Time pressure encourages trial-and-error building, and candidates do not rehearse translating a written process definition into a stage plan.
What to do instead
Practise producing a short written design first: inputs, outputs, stages, decision points, and exception routes. Then build to that design and compare the finished flow against it before considering the task done.