Blue Prism Pro Developer common mistakes
Blue Prism Pro Developer · Understand the traps and how to avoid them.
Building one monolithic process that performs every step in a single page instead of decomposing work into reusable sub-pages and objects, then failing scenario questions that ask how to restructure a solution for reuse or parallelism.
Candidates who learned by automating small tasks end up with linear, single-page flows and never internalise the layered architecture (process, sub-process, object, shared business objects) that the exam treats as the default design vocabulary.
What to do instead
Before answering any architecture question, sketch the intended layering: a driver process that reads queue items, sub-pages for each logical phase, and object pages that own application interaction. Practise refactoring a linear flow into named sub-pages and justify each boundary by reuse or failure isolation.
Using a decision stage with a bare yes/no branch where a multi-way choice is needed, and forgetting to set an explicit default or 'otherwise' route, so an unexpected value silently falls through to the wrong path.
The decision stage's expression and branch wiring look trivial, so candidates wire two outputs and assume all cases are covered, overlooking that empty strings, nulls and new enumerations need an explicit catch-all.
What to do instead
Always model decisions as complete: enumerate every expected value, add a final catch-all branch that throws a designed business exception or logs and routes to a safe exit, and test with an empty or unexpected value to confirm the catch-all fires.
Writing loop logic that never terminates or skips records, typically by incrementing the counter in the wrong place, looping over a collection while deleting from it, or relying on the collection's size being re-evaluated each pass.
Blue Prism collections change size during iteration and the loop decision is evaluated before or after the counter increment depending on stage order; candidates reason about loops as if they were ordinary for-each constructs in a general-purpose language.
What to do instead
Capture the collection's count into a numeric data item before the loop, iterate on that fixed bound, increment the counter as the first action inside the loop body, and never remove rows from the collection being iterated. Trace one iteration on paper with concrete index values before running.
Spying elements with the wrong mode for the technology in use, for example using HTML mode on a surface that needs accessibility or region mode, or spying a container instead of the individual control, producing attributes that break on the next screen state.
The spying wizard defaults to whichever mode worked in the last session, and candidates accept the first highlighted match without verifying that the captured attributes are stable across the states the process will actually encounter.
What to do instead
After spying, open the element's attributes and confirm the match is anchored on stable identifiers such as element id or path rather than volatile text or coordinates. Test the element in Application Modeller's highlight and validate functions against at least two different runtime states, and re-spy with a different mode if the match is not unique.
Treating a recoverable business exception and a system exception as interchangeable, catching everything in one block, or letting a system exception be swallowed so the work queue item is marked complete despite an application failure.
Both appear as exceptions in the flow, and candidates focus on making the process continue rather than on the semantic difference: business exceptions mean the item is invalid, system exceptions mean the environment failed and the item should be retried.
What to do instead
Classify deliberately: throw business exceptions for data that can never succeed (mark the item exceptioned), and let system exceptions propagate to a recovery block that preserves the item and retries. Never place a blanket recovery that converts system failures into successful completions; verify the queue item status after each test.
Designing queue items that carry no meaningful key or status data, then being unable to answer questions about deferred items, item locking, or how to prevent duplicate processing of the same record.
Candidates treat the queue as a simple to-do list and populate only a free-text description, missing that the exam tests item keys, tags, priorities, deferral and the load-into-queue pattern as first-class design decisions.
What to do instead
For every queue, define the item key from the source system's unique identifier, add tags for filtering and reporting, and decide explicitly whether duplicates are prevented at load time or handled at processing time with an item-already-exists check. Practise writing the load stage that sets key, priority and deferral date.
Ignoring session and resource constraints when answering Control Room and scheduling questions, such as assuming a schedule can run on any resource regardless of the process's target application or that multiple sessions of the same process can share one resource.
Candidates memorise the schedule dialog's fields without building a mental model of resources, sessions and the runtime resource's single-session-per-process constraint, so they propose configurations that cannot actually be deployed.
What to do instead
Learn the hierarchy explicitly: a runtime resource hosts sessions, each session runs one process, and a schedule triggers a process on a named resource. Before answering, state which resource the process runs on and whether a second concurrent session would conflict with the target application's licensing or login model.
Answering governance questions by describing technical controls only, omitting the separation-of-duties and change-control artefacts such as release approval, environment promotion evidence and role assignment justification.
Developers think in terms of what the code does, so they answer 'who can do what' questions with feature descriptions rather than the governance process that authorises and records the change.
What to do instead
For any governance scenario, structure the answer around three things: the role that permits the action, the evidence produced when the action occurs (audit log, release record, approval), and the environment stage where it is allowed. Practise phrasing answers in that order.
Assuming a role with broad permissions in a development environment will behave identically in production, or forgetting that object and process access rights are granted per role and per folder-like grouping rather than globally.
Candidates test only in a permissive development environment where their account is an administrator and never observe the access-denied behaviour that a restricted production role produces.
What to do instead
Map each task to the minimum role that performs it, then verify by logging in as a user with only that role and attempting the action. Note which rights are needed for design, for running in Control Room, and for schedule management, and state the environment where each role is granted.
Hard-coding environment-specific values such as URLs, credentials, file paths or queue names directly into process or object stages instead of externalising them to environment variables or credentials, then failing questions about promoting a solution between environments.
Hard-coded values work in the developer's environment and the failure only appears after promotion, so the habit persists until an exam scenario forces the candidate to reason about environment portability.
What to do instead
Adopt a rule: any value that differs between development, test and production lives in an environment variable or credential store and is referenced by name in the process. When reviewing a design, list every literal in the flow and move each environment-dependent one out; practise describing the promotion checklist from development to production.