Pega Robotics System Architect (CPRSA) flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

RPA candidate criteria

High volume, rules-based, stable input format, deterministic outcome, and digital data access. Processes failing any criterion need redesign or human-in-the-loop before automation.

Straight-through processing rate

Percentage of cases completed end to end with no human intervention. Calculated as untouched cases divided by total cases, times one hundred.

Business exception

A case where input data is valid but a business rule prevents completion, such as a denied claim. It routes to a human work queue rather than triggering a retry.

System exception

A technical failure such as an unavailable application or unmatched UI element. It triggers error handling and retry logic before any human escalation.

Attended automation

A robot runs on the operator's desktop and assists in real time while the human retains the decision. Suited to judgment-heavy steps with repetitive data gathering.

Unattended automation

A robot runs without a human present, triggered by schedule or event. Requires deterministic rules, defined exception routing, and operations monitoring.

Work queue design rule

Create one queue per business outcome or skill group, not per application. Queue assignment determines which human or robot skill receives the item.

Process baseline metrics

Volume per period, arrival pattern, peak concurrency, and current cycle time captured before go-live. Without them, ROI and capacity claims cannot be validated.

As-is process decomposition

Break the flow into business steps and label each automated, manual, or hybrid. A step is automatable only when inputs, rules, and exceptions are documented.

Screen change impact

Any upstream layout or data contract change is a regression risk for every automation touching that screen. A notification path belongs in the operating model.

Diagnostic order rule

Check trigger fired, then application session state, then UI element match, then data values. Fix only the earliest failing stage before retesting.

Stable element properties

Prefer automation ID, name, and control type over coordinates, index position, or dynamic text. Anchor to a stable neighbor when no unique property exists.

Idempotent retry rule

Retry only operations safe to repeat. Submitting payments or sending email requires a deduplication key check before any retry to prevent duplicate transactions.

Configurable timeout design

Set explicit waits per interaction class such as window load, element present, and network response. Keep them configurable so environment differences need no rebuild.

Single-case reproduction

Run one case in debug mode, log runtime state, then replay. Failure to reproduce points to concurrency, timing, or environment drift rather than logic error.

Empty collection handling

Every loop must define behavior for empty collections, partial failure mid-loop, and duplicate keys. Unhandled empty collections are a common production defect.

Credential vault rule

Store credentials in a secure vault, never in project files. Detect the login screen on session expiry instead of assuming a fixed session lifetime.

Latency triage split

Separate robot-side latency such as UI waits and image matching from server-side response time and queue depth. Only the robot-side portion is fixable by design.

Unique property selection

Choose matching properties that identify exactly one element on the target screen. A property matching several elements causes ambiguous matches and intermittent failures.

Concurrency defect signature

Failures that appear only under parallel load, never in single-case replay, typically indicate shared state, timing races, or resource contention rather than faulty logic.

Exception path coverage

For each automatable step, document the decision rules and every exception branch. Undocumented exception paths are the leading cause of production stops.

RACI for automation delivery

Business owner owns process definition and acceptance criteria; architect owns design; operations owns schedule and incidents; IT security owns access approval.

Release readiness gate

Go-live requires 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 covering restart and rollback steps.

Post-go-live change control

Any change to a business rule, screen, or credential path goes through a change ticket assessing impact on all dependent automations, not just the one changed.

Severity escalation contract

Severity levels defined by business impact, each with named contact, response time, and whether the robot pauses or continues on error.

Shadowing elicitation technique

Observe a human operator through a full cycle and record every application, copy-paste, and workaround. Interviews alone miss undocumented steps.

Iteration demo cadence

Demonstrate working automation with real business data at the end of each iteration. Business reviewers catch rule gaps that technical review misses.

Sensitive data agreement

Agree in advance which fields are sensitive, whether logging or recording captures them, and what retention applies, so audit needs are designed in.

Operations runbook contents

Restart procedure, rollback steps, monitoring checks, escalation contacts, and known limitations. Operations uses it without needing the original developer present.

Acceptance criteria ownership

The business owner defines and signs off acceptance criteria in business terms such as accuracy, cycle time, and exception rate, not technical implementation details.

Dependent automation inventory

A maintained list of every automation that touches a given application or credential path, used to scope impact when that dependency changes.