Blue Prism Solution Designer cheat sheet

Solution design starts from the process inventory: every candidate process is classified as automated, partially automated, or manual before any build begins.

The PDD (Process Definition Document) is the design authority for business logic; the SDD (Solution Design Document) records technical architecture, work queues, and exception strategy.

Design the queue structure first: one queue per distinct work type, with key fields chosen so a case can be uniquely identified and re-queried without duplication.

A solution is decomposed into layers: process layer (orchestration and business flow), object layer (application interaction), and shared components (work queues, credentials, logging, environment variables).

Environment variables hold all environment-specific values (URLs, credentials, file paths); hard-coded values in processes are a design defect.

Exception handling is designed at three levels: recoverable (retry), business (mark exception and continue), and system (stop the process and alert).

Non-functional requirements to capture in design: throughput per hour, peak concurrency, maximum case age before escalation, and audit retention period.

Session and licence design must state how many concurrent runtime resources are required, derived from volume divided by acceptable cycle time.

A process is a sequence of stages, each stage a page; a page should perform one logical unit of work and be independently testable.

Main process pages handle happy path only; exception pages handle business exceptions; recovery pages handle system exceptions and cleanup.

Every loop over a collection must have a defined termination condition and an iteration cap to prevent infinite loops.

Work queue items move through states: Pending, In Progress, Exceptioned, Completed; deferred items carry a defer-until date for retry.

Retry logic belongs at the queue level: set max retries per item; on final retry failure, mark the item as an exception for human review.

A process must be idempotent where possible: re-running the same case must not duplicate downstream transactions; use reference keys to detect prior completion.

Data items scope: use local variables inside pages and only promote to global data items when the value must survive page transitions.

Business rules that change frequently belong in a lookup table or configuration data item, not embedded in decision stages.

Objects are split into application modeller (the interface definition) and business objects (the actions exposed to processes).

Every business object action should be atomic, single-purpose, and return a consistent output: success flag, output data, and exception detail.

Spy modes are chosen per element type: HTML mode for web, Win32/UIA for thick clients, Accessibility for Java applications, Region for image-only targets.

Use match attributes in priority order: path, then stable attributes (ID, name), then position or index only as a last resort.

Wait stages must precede every read or write on an element that may not be immediately present; fixed sleeps are a design defect.

Credentials are retrieved via the credential manager at runtime; never store passwords in process or object data items or in logs.

Objects must expose a clean interface: no UI-specific data items leak to the process layer; conversions happen inside the object.

Attach/detach lifecycle: attach once per case where possible, detach in a recovery block so orphaned sessions do not accumulate.

Delivery phases: process definition, solution design, build, unit test, integration test, UAT, go-live, hypercare.

Unit testing covers each page and each object action in isolation; entry criteria require the SDD signed off.

Integration testing proves the process and object layers work together against a representative test environment with realistic data volumes.

UAT is executed by business owners against agreed acceptance criteria recorded in the PDD; defects are triaged by severity before go-live.

Release packaging: the release is exported as a Blue Prism release file; the release number is incremented and recorded against the change ticket.

Rollback plan must specify the prior release version, the database backup point, and the owner authorised to trigger rollback.

Hypercare period is typically two to four weeks with daily queue health checks, exception rate monitoring, and a defect log.

Deployment checklist: environment variables verified per environment, credentials present, schedules enabled, queue defined, logging level set.

A centre of excellence owns standards, the design authority review, reusable components, and the automation pipeline.

Design authority sign-off is a gate: no build starts without an approved SDD; no go-live without approved test evidence.

Role separation: developer builds, tester verifies, and a separate approver promotes to production; the same person cannot do all three.

Audit logging records every queue item state change, every process start and end, and every user login; logs are retained per policy.

Change control: every change to a production process requires a change request, impact assessment, test evidence, and scheduled deployment window.

Access control uses role-based permissions; production access is restricted to the operations team, and developers get read-only access.

Exception rate is the primary health metric: a sustained rise above the agreed threshold triggers a root-cause review.

Periodic review: processes are re-baselined against the PDD at least annually or when the underlying application changes.