Process Design and Solution Architecture
Start with the process, not the stages
Blueprinting is the heart of this domain. Before touching Process Studio, a Pro Developer can explain the business process in plain language, split it into a main process and reusable sub-processes, and decide which work belongs in Process Studio (business logic, orchestration) versus Object Studio (application interaction). Understand the standard Blue Prism layering: a Process calls Objects and Sub-Processes; Objects expose Actions; VBOs (Visual Business Objects) wrap one application each. Separation of concerns is the guiding principle - business rules must not be buried inside an object, and application-specific clicks must not live in a process.
Architecture concepts to know
Be comfortable with the purpose of the Process layer, Object layer, and the shared Work Queue as the hand-off mechanism. Know when to use a Sub-Process (reusable, called via the Start stage) versus an Object (talks to an app). Understand session variables versus environment variables: environment variables are configuration held centrally and should be referenced, not hard-coded. Exception handling strategy is also an architecture decision - where exceptions are caught, what is retried, and what is deferred to a queue.
Traps in questions
Questions frequently test 'where does this logic belong?' - a rule such as 'if invoice > 10,000 route to manager' is process-layer logic, while 'click the Save button' is object-layer. Another trap: treating objects as places for business validation, or putting application credentials in the process instead of an environment variable. Also watch for answers that recommend one giant process with no reusable components.
Rule of thumb
If two processes could plausibly need it, it belongs in a shared Sub-Process or Object, not copy-pasted. Design for the second consumer.