Blue Prism Developer cheat sheet

A Blue Prism process is a directed graph of stages; execution follows link order, and a stage with two outgoing links requires a decision (Choice or Decision stage) rather than implicit branching.

Decompose by exception boundary: a stage belongs in a separate Page when it can fail independently, is reused by two or more callers, or exceeds roughly one screen of stages on the canvas.

Page input and output parameters are the only supported data contract between a Page and its caller; global data items act as process-wide state and should be limited to values that genuinely persist across Pages.

The standard Blue Prism lifecycle order is Process Model, then Process, then Object, then Release, with each layer owned by a distinct role in the delivery methodology.

A Process Model defines the stages of a business process (for example Main Process, Exception, and Cleanup), while a Process implements one stage of that model as executable logic.

Loop constructs are built from a Decision stage plus a Jump or the built-in Loop stage; every loop must have an explicit termination condition and a counter to prevent infinite execution.

Work queues are the correct mechanism for distributing case-level work across digital workers; the queue item key must be unique per business case to prevent duplicate processing.

Naming conventions: prefix data items by type (for example dte for date, num for number, txt for text) and give Pages verb-led names so the process graph reads as a sequence of actions.

Never place environment-specific values (URLs, credentials, file paths) in process logic; store them in Environment Variables or Credentials so the same release promotes across environments.

Process Studio runs process logic against business objects; Object Studio runs the internal logic of a single business object and cannot be launched directly from Control Room.

The Object Studio action model is one Action per business capability, with inputs and outputs declared on the Action's Start and End stages; Actions must be stateless between calls.

The Application Modeller defines the target application's element tree; each element carries attributes used for matching, and match precedence determines which attributes are tried first.

Element match types include Window Text, Class Name, Control ID, and ordinal position; prefer stable attributes such as Control ID or a unique label over volatile ones like screen coordinates.

Spy modes: Win32 mode targets native Windows controls, Accessibility mode targets UI Automation and Java applications, Browser mode targets HTML elements, and Region mode falls back to image matching.

The Navigate stage performs clicks, keystrokes, reads, writes, and global sends; global send keys go to the foreground window and are less reliable than element-targeted actions.

A Read stage returns element text into a data item; a Write stage pushes a data item into an element. Both require an element reference from the Application Modeller.

Use a Wait stage with a timeout before interacting with a newly opened window; the Wait stage polls for element existence and raises an exception when the timeout elapses.

The Code stage executes VBScript or C# and can reference data items; it is appropriate for string parsing and date arithmetic that stages cannot express cleanly.

A business object exposes Actions to processes; the object's internal Pages handle application navigation, and the process layer should never depend on object internals.

Objects that target the same application should share one Application Modeller definition so element changes are maintained in a single place.

Use a Login action that is idempotent: check whether a session already exists before authenticating, so repeated calls do not open duplicate sessions.

Read actions should return typed outputs (text, number, date, flag) rather than raw screen scrapes, so the process layer can validate and branch on them.

For web applications, prefer HTML-mode spying with element attributes over coordinate-based clicks; for Citrix or virtual desktops, use surface automation with image and region matching.

Business object Actions should be granular enough to be reused (for example Get Customer, Create Order) but coarse enough that a process does not orchestrate every keystroke.

External integrations (REST, SOAP, database) are implemented inside objects using the appropriate VBO or Code stage, with timeouts and retry logic contained in the object.

Every object Action must have a documented input and output contract; undocumented side effects make objects unsafe to reuse across processes.

Recover stages define the recovery path for a Page; when an exception is thrown, execution resumes at the Recover stage in the same Page, and the exception detail is available in the exception data item.

The Recover stage's Resume stage must be set to a stage that can legitimately continue, commonly the start of the Page or the cleanup block; resuming mid-transaction risks partial state.

Block stages group stages so that an exception inside the block is handled by the block's Recover stage rather than propagating to the Page-level handler.

Preserve the original exception text and stack when rethrowing; overwriting the exception detail with a generic message destroys the diagnostic information needed in Control Room.

Business exceptions (for example invalid input data) should mark the work queue item as an exception with a reason, while system exceptions should trigger retry logic before being escalated.

Retry logic belongs inside the object or the process loop with a bounded attempt count; unbounded retries can stall a digital worker indefinitely.

A Cleanup section in the process should release application sessions, close windows, and mark queue items, so that an exception does not leave orphaned sessions.

Throwing an exception is done with the Exception stage, which accepts an exception type and a detail string; unhandled exceptions surface in Control Room session logs.

Control Room manages queues, processes, schedules, digital workers, and sessions; a session is one running instance of a process on one resource.

A release is a versioned package of processes, objects, and resources; only released content can be run from Control Room, and changes require a new release.

Work queue items have states: New, In Progress, Exception, Completed, and Deferred; Deferred items are retried after a configured delay.

Queue item locking prevents two digital workers from processing the same item; a lock is released when the session ends, so crashed sessions can leave items locked until the lock expires.

Schedules define start times, recurrence, and the resource or pool that runs the process; a schedule can be run manually from Control Room for testing.

Role-based access control assigns permissions per role; a developer role can edit processes, while an operator role can start and stop sessions but not modify logic.

Audit logs record user actions, session starts and stops, and configuration changes; they are the evidence source for governance reviews.

Environment variables and credentials are managed centrally and injected at runtime; credentials are encrypted and never visible in plain text to operators.

Session logs capture stage-level execution detail and exception messages; the log level is configurable and higher verbosity increases log volume and storage cost.