BJSC MCQ common mistakes
BJSC MCQ · Understand the traps and how to avoid them.
Treating a Blue Prism 'Process' and an 'Object' as interchangeable containers, so the candidate builds business logic inside an Object or tries to attach an Application Modeller to a Process.
Both are built in the same diagramming surface with the same stages, so the visual similarity hides the architectural split: Processes orchestrate business flow and hold no application modelling, while Objects encapsulate application interaction and own the Application Modeller and its elements.
What to do instead
Before answering, ask what the artifact is responsible for. If the item mentions Application Modeller, application elements, or a specific system, it is Object Studio. If it mentions work queues, case data, or multi-step business logic, it is Process Studio. Memorise the one-line rule: Objects talk to applications, Processes talk to Objects.
Reading an exception-handling question as 'what should the developer do to prevent this error' and choosing the design fix, when the question asks what happens at runtime inside the Block, Recover, Resume structure.
Candidates conflate the two layers of error management: the runtime behaviour of the exception stages versus the design-time practice of validating inputs and avoiding the exception altogether. Both are legitimate topics, so the stem's exact verb determines the answer.
What to do instead
Underline the verb in the stem. 'What happens when', 'which stage executes next', and 'what is the state of the item' point to runtime stage behaviour. 'What is the best design', 'how should the developer prevent', and 'which practice reduces' point to design guidance. Answer only the layer the verb names.
Assuming an exception caught and handled inside an Object is automatically visible to the calling Process, and therefore selecting an answer where the Process reacts to a detail the Object already swallowed.
Objects and Processes have separate exception scopes. If an Object handles its own exception with Recover and Resume, the Process never sees it unless the Object deliberately re-throws or returns a status output. Candidates who do not track scope boundaries pick answers that leak information across the boundary.
What to do instead
Draw the call stack on scratch paper: Process page, Object page, Block. Mark where each Recover sits. Only exceptions that escape the Object's Block reach the Process. Where a question hinges on the caller knowing about a failure, the correct design passes a status or throws deliberately rather than silently recovering.
Confusing a work queue item's status transitions, for example treating 'Exception' as a terminal state or assuming a 'Completed' item can be reworked without an explicit action.
Queue statuses are a small closed set with specific transitions, and candidates learn them as a list rather than as a state machine. Without the transitions, similar-sounding options such as Locked, Pending, Deferred, and Exception become interchangeable in the candidate's mind.
What to do instead
Memorise the queue item lifecycle as a diagram: item added as Pending, fetched and Locked to a resource, then Completed, Exception, or Deferred. Note which transitions require a deliberate action, such as deferring until a date or marking an exception as retryable. Answer status questions by locating the item on that diagram, not by recalling a list.
Choosing the answer that makes the robot 'more robust' by adding retries everywhere, instead of matching the recovery strategy to the type of failure described in the scenario.
Candidates equate resilience with retrying. In practice, retrying a business exception such as an invalid customer record wastes cycles and can corrupt downstream data, while retrying a transient system exception is exactly right. The exam tests this distinction and rewards the discriminating answer.
What to do instead
Classify the failure first: is it a system exception (environment, timing, connectivity) or a business exception (data or rule violation)? Retry and recover for system exceptions; do not retry business exceptions, instead route the item to an exception queue or mark it Exception with a clear reason. Select the option that reflects the classification in the stem.
Answering Application Modeller questions from general UI-automation intuition rather than from how Blue Prism matches elements, for example assuming a single match attribute is always sufficient or that any attribute can be used for matching.
Candidates with experience in other automation tools carry assumptions about selectors and XPath that do not map onto Blue Prism's element attributes and match settings. The exam tests Blue Prism's own attribute and match-configuration behaviour.
What to do instead
Learn the element attribute set and which attributes are reliable for matching versus which are volatile. Understand that match attributes should be chosen for stability and uniqueness, and that wildcards and dynamic attributes exist for values that change. When a question describes an element that fails to be found, look for the answer about match attributes and wildcards, not about waits or retries.
Treating the Control Room as a passive dashboard and selecting answers that describe manual intervention as the normal operating model, rather than as the scheduling, session, and resource management tool it is.
Candidates skim Control Room material because it feels administrative, then fall back on generic IT-operations instincts. The exam tests specific concepts such as resource pools, session logs, schedules, and how work is distributed to available resources.
What to do instead
Study Control Room as a set of named mechanisms: resources, pools, sessions, schedules, and logs, and know what each one controls. For scenario questions, ask which mechanism the stem is describing before evaluating options, so the answer is anchored to a specific Control Room feature rather than to general operations practice.
Designing or evaluating a solution as a single monolithic Process, and rejecting answers that split work into a Process plus reusable Objects plus a queue-driven work allocation model.
Candidates reason from scripting habits, where one linear script is simplest. Blue Prism's delivery model rewards separation of concerns, reusability, and queue-based scalability, so the 'simplest' answer is often the wrong one on design questions.
What to do instead
Adopt a default architecture for design questions: a thin Process that orchestrates, Objects that encapsulate each application, and a work queue that supplies and tracks items. When two options are functionally equivalent, prefer the one with clearer separation, greater reusability, and better queue-based scaling.
Ignoring the difference between design-time validation and runtime behaviour when a question asks what a specific stage or setting will do, and answering from what the candidate wishes it did.
Blue Prism distinguishes what the studio checks or warns about while building from what actually executes at runtime. Candidates who have not separated these layers pick answers that describe intended behaviour rather than actual behaviour.
What to do instead
For every stage or setting in a question, state explicitly what it does at runtime and, separately, what the studio validates at design time. If the stem asks about execution, answer from runtime semantics only. Where the two diverge, note the divergence, because that gap is a common source of exam distractors.
Spending equal time on all six domains and never drilling the two highest-density areas, so recall is shallow exactly where the most questions are drawn from.
Candidates revise by reading notes cover to cover, which feels productive but distributes effort evenly. Exam weighting is not even, and the process, object, and exception domains carry disproportionate question counts.
What to do instead
Weight revision to the blueprint. Build a one-page summary for Process Studio stages, Object Studio and Application Modeller, and the exception-handling model, and rehearse those from memory until you can reproduce them unprompted. Treat the remaining domains as supporting material to be reviewed after the core three are solid.