Pega Robotics System Architect (CPRSA) cheat sheet

Automation candidacy rule: a process is a strong RPA candidate when it is high-volume, rules-based, stable in input format, and has deterministic outcomes; processes requiring subjective judgment are deferred to assisted automation or human-in-the-loop.

Process decomposition: model the as-is flow as a sequence of business steps, then mark each step as automated, manual, or hybrid; a step is only automatable if its inputs, decision rules, and exception paths are documented.

Straight-through processing (STP) rate = (cases completed with no human touch / total cases) x 100; it is the primary business KPI reported for a deployed Pega Robot Manager solution.

Handle time and AHT (average handle time) reductions are measured per transaction type, not per robot, because a single robot may serve several queues with different service-level targets.

Exception taxonomy: business exceptions (valid data, rule says stop, e.g. claim denied) route to a work queue for a human; system exceptions (application down, element not found) route to error handling and retry logic before escalation.

Work queue design rule: one queue per business outcome or skill group, not per application; queue assignment determines which human or robot skill receives the work item.

RPA fits attended automation when a human must make the final decision and the robot performs keystroke-level data gathering; it fits unattended automation when the trigger is scheduled or event-driven and no human is present.

Process performance baselines must be captured before go-live: volume per period, arrival pattern, peak concurrency, and current cycle time; without a baseline, ROI and capacity claims cannot be validated.

Change impact rule: any change to the upstream source system's screen layout or data contract is a regression risk for every automation that touches it, so a screen-change notification path belongs in the operating model.

Diagnostic order for a failing automation: confirm the trigger fired, confirm the target application and session state, confirm UI element match, then confirm data values; fix the earliest failing stage only.

Element matching strategy: prefer stable, unique properties (automation ID, name, control type) over volatile ones (screen coordinates, index position, dynamic text); if no stable property exists, anchor to a stable neighboring element.

Retry logic rule: retry only idempotent operations; a retry on a non-idempotent step (submit payment, send email) risks duplicate transactions unless a deduplication key is checked first.

Timeout design: set explicit wait timeouts per interaction class (window load, element present, network response) and make them configurable rather than hard-coded, so environment differences do not require a rebuild.

Root-cause isolation: reproduce the failure with a single case in debug mode, log the runtime state, then replay; if it does not reproduce, suspect concurrency, timing, or environment drift rather than logic error.

Robustness rule: every loop over a collection must define behavior for empty collection, partial failure mid-loop, and duplicate keys; unhandled empty collections are a common production defect.

Credential and session handling: store credentials in a secure vault, never in project files; handle session expiry by detecting the login screen rather than assuming a fixed session lifetime.

Performance triage: separate robot-side latency (UI waits, image matching) from server-side latency (response time, queue depth); only the robot-side portion is fixable by automation design.

RACI for an automation delivery: business owner owns the process definition and acceptance criteria; system architect owns the design; operations owns the run schedule and incident response; IT/security owns access approval.

Deployment gate rule: a solution is release-ready only after business sign-off on acceptance criteria, IT sign-off on credentials and access, and operations sign-off on monitoring and escalation contacts.

Handover artifact set: process design document, solution design document, test evidence, known limitations list, and an operations runbook with restart and rollback steps.

Change control: any post-go-live change to a business rule, screen, or credential path goes through a change ticket with impact assessment on all dependent automations, not just the one being changed.

Escalation contract: define severity levels by business impact (blocked revenue, regulatory deadline, internal-only), each with a named contact, response time, and whether the robot pauses or continues on error.

Requirement elicitation technique: shadow the human operator for a full cycle and record every application touched, every copy-paste, and every exception; interviews alone miss undocumented workarounds.

Stakeholder review cadence: demo at the end of each iteration with real data from the business, because business reviewers catch rule gaps that technical review does not.

Security and audit collaboration: agree in advance which fields are sensitive, whether screen recording or logging captures them, and what retention applies, so audit requirements are designed in rather than retrofitted.