Blue Prism Solution Designer common mistakes
Blue Prism Solution Designer · Understand the traps and how to avoid them.
Treating the Process layer as the place to build page interactions, putting application navigation and element reads inside Process stages instead of calling reusable Object actions.
Candidates who learned automation by recording steps conflate 'the thing that runs' with 'the thing that touches the app'; the exam's layered model (Process = orchestration and business flow, Object = application interaction) is easy to recite but easy to violate when sketching a design under time pressure.
What to do instead
Before answering any design question, classify each described step as business decision, orchestration, or application contact. Anything that touches a target application belongs in an Object action with defined inputs/outputs; the Process should contain only calls, decisions, and data handling. Practise redrawing a scenario into a two-column Process/Object split until it is automatic.
Designing exception handling as a single catch-all that logs and terminates, without distinguishing business exceptions from system exceptions or defining recovery and retry behaviour.
Real builds often start with a minimal 'On Error, mark failed' block that works in testing; candidates carry that habit into the exam and miss questions about recoverable system exceptions, retry counts, and safe resumption points.
What to do instead
For every scenario, state explicitly: which conditions are business exceptions (expected, handled by flow logic, no retry), which are system exceptions (transient, retry with a bounded count and delay, then escalate), where the work item's status is set, and what data must be preserved to resume. Write the recovery path as a numbered sequence, not a sentence.
Ignoring the Work Queue as the unit of control and describing a design that loops over an in-memory collection instead of queue items with defined statuses, keys, and tags.
Simple demos process a list read from a spreadsheet in one run; that pattern is comfortable and appears to satisfy the requirement, so candidates overlook scalability, retry, and multi-run resumption concerns the exam is testing.
What to do instead
Default every high-volume or resumable design to a queue: define the unique key, what constitutes one item, how items are deferred or tagged for priority, how exceptions set item status, and how a restarted process picks up remaining items. Only choose in-memory iteration when the scenario is genuinely single-run and small, and say why.
Producing a design with no stated non-functional targets - no throughput estimate, no timing of the target application's peak load, no session/concurrency plan.
Candidates focus on functional correctness because that is what they build day to day; capacity and scheduling reasoning is unfamiliar and feels like guesswork, so it gets skipped rather than estimated.
What to do instead
Attach numbers to every design: items per run, run frequency, average handling time per item, number of concurrent interactive sessions versus background runtime resources, and the window in which the automation must not compete with users. Even rough arithmetic demonstrates the control the exam rewards; state assumptions explicitly when data is missing.
Skipping the design authority and re-usable component review, presenting a solution that duplicates an existing shared object or page rather than reusing or extending it.
Candidates answer as if designing in isolation; in practice the exam expects awareness that a central team owns the component library and standards, and that duplication is a governance failure, not just an efficiency one.
What to do instead
In any design answer, include an explicit step: check the component library and existing processes for reusable assets, record the reuse decision, and route new reusable candidates back to the owning team. Name the artefact (design document, component register entry) rather than describing the intent vaguely.
Writing object actions with no defined input/output contract, no pre-condition checks, and no post-condition validation, so the caller cannot tell success from silent failure.
Builders often let an action 'just work' against a stable test system and rely on the next stage to notice problems; the exam tests whether actions are self-contained, verifiable units.
What to do instead
For each action, specify inputs with types and validation, outputs including a success indicator, pre-conditions such as expected screen state, and post-conditions such as a confirmation value read back. Make failure explicit via the action's outputs or a thrown exception with a stable code, never a silent no-op.
Describing spying and element identification loosely, without addressing application modes, attribute selection, or how the element survives minor UI change.
Candidates rely on the default spy mode that worked for them and do not reason about why one mode is chosen over another or which attributes are stable; questions framed around resilience expose this gap.
What to do instead
For each target application, state the chosen integration mode and justify it, list the attributes relied on (prefer stable, application-assigned identifiers over positional or text attributes), and note the fallback if the primary element fails. Where relevant, mention matching by more than one attribute and testing against a second environment.
Omitting the operational wrapper from the design: no logging standard, no MI/audit data captured per case, no retention or reconciliation approach.
Design effort concentrates on the happy path through the application; reporting and audit are treated as afterthoughts even though they determine whether the solution can be supported and evidenced.
What to do instead
Add a data section to every design: what is captured per item (case reference, timestamps, outcome, exception reason), where it is written, who consumes it, and how it reconciles to source volumes. Tie logging to the exception taxonomy so failures are diagnosable without re-running.
Presenting a design without a delivery plan: no staged build, no test approach covering unit, process, and user acceptance levels, no cutover or rollback position.
Candidates treat the exam as a pure design exercise and forget that the delivery domain tests whether the solution can be built, verified, and transitioned in a controlled way.
What to do instead
For delivery questions, always cover: build sequence and dependencies, test data and environment needs, the levels of testing and who signs each off, parallel-run or pilot approach, go-live criteria, and rollback if acceptance fails. Keep it specific to the scenario rather than reciting a generic methodology.
Answering governance questions by naming a document ('there is a design document') rather than describing the control it exerts - who reviews, at which gate, against what criteria, and what happens on rejection.
Candidates memorise artefact names from the delivery lifecycle but not the decision points, so answers sound compliant while containing no actual control mechanism.
What to do instead
Describe each governance point as a gate: entry criteria, reviewer role, evidence examined, possible outcomes, and the record produced. Where a design deviates from standards, state the exception route and who approves it. Convert every 'we have a document' statement into 'this person checks this against this at this point'.