Pega Robotics System Architect (CPRSA) key terms

A standardized diagramming language for drawing business workflows with events, tasks, and gateways. In automation projects it gives the system architect a shared picture of the process before any robot is designed.

The structured activity of interviewing stakeholders, observing work, and reviewing system logs to learn how a process actually runs. It surfaces the real variations and workarounds that documentation usually omits.

The documented description of how work is performed today, including manual steps, delays, and rework. It is the baseline against which automation benefits and future redesign are measured.

The redesigned version of a workflow after automation and simplification decisions are made. It defines which steps the robot performs, which stay human, and where handoffs occur.

The scoring and prioritization of candidate workflows for automation based on volume, stability, rule-based logic, exception rate, and expected return. It prevents teams from automating low-value or fragile work first.

An assessment of how much of a process can realistically be handled by software robots, given rule clarity, data quality, and system access. High-potential steps are repetitive, deterministic, and digital.

The financial benefit of an automation compared with its build and run costs, usually expressed as payback period or annual savings. Architects use it to justify scope and defend design trade-offs.

The person who performs or supervises a process daily and can explain its exceptions, tribal knowledge, and hidden dependencies. Architects rely on SMEs to validate designs and test robot behavior.

Building shared agreement among business owners, IT, compliance, and operations on automation goals, scope, and success measures. Misalignment is a leading cause of stalled deployments.

The practice of linking each business requirement to a design element, test case, and acceptance criterion. It lets the team prove the delivered automation matches what was agreed and approved.

The planned communication, training, and support that helps staff adopt automation without resistance. It addresses role changes, new approval duties, and fears about job displacement.

A design in which a person reviews, approves, or completes steps the robot cannot decide alone. It is used for judgment calls, high-value exceptions, and regulated decisions requiring accountability.

The designed response when a robot meets unexpected data, missing records, or system errors. Good designs classify exceptions, retry where safe, and route unresolved cases to a person with context.

A case where the input or situation falls outside normal business rules, such as a missing signature or an invalid claim. It usually requires human judgment rather than a technical fix.

A technical failure during execution, such as an application crash, timeout, or unavailable server. These are often transient and may be resolved by retry or by waiting for the target system.

A configured rule that repeats a failed action a set number of times, often with a delay, before escalating. It handles transient faults without human intervention but must avoid duplicate side effects.

A property of an operation that produces the same result whether executed once or several times. Designs need it so retries after a timeout do not create duplicate orders or payments.

The ability of a robot to resume work after a crash or interruption without losing or repeating transactions. It depends on persistent state, checkpoints, and clear restart rules.

A saved marker of progress that lets an automation restart from a known good point rather than from the beginning. Checkpoints reduce reprocessing and protect against duplicate side effects.

The guarantee that a unit of work is completed fully or not at all, leaving source and target systems consistent. Architects enforce it through ordering, validation, and reconciliation controls.

A control that compares what the robot processed against source records or downstream systems to detect mismatches. It is a key evidence source for audit and operational confidence.

A workflow whose outcome is fully predictable from its inputs and rules, with no subjective judgment. Such processes are the strongest candidates for unattended automation.

A stated policy or condition that governs a decision in a process, such as an approval threshold or eligibility test. Clear, stable rules are what make automation reliable and testable.

A tabular way to express combinations of conditions and their resulting actions. It makes complex branching logic visible so business users can review it and testers can cover every path.

Execution that runs on a schedule or trigger without a person present at the machine. It suits high-volume, stable processes but demands strong monitoring and exception routing.

Execution that runs on a user's desktop and is started or assisted by that person during their work. It fits processes needing human judgment, local applications, or real-time customer interaction.

The coordination of multiple robots, queues, and systems so work is distributed and sequenced correctly. It covers starting jobs, balancing load, and tracking status across the estate.

A managed list of work items that robots pull from, with statuses such as new, in progress, and failed. Queues decouple data collection from processing and enable retries and load sharing.

The configuration of when automations start, whether by time, interval, or event trigger. Poor scheduling causes contention on target systems or missed business deadlines.

The period of highest transaction volume or system demand that an automation must withstand. Designs must account for it so robots do not overwhelm shared applications or breach service levels.

The ability of an automation design to handle growing volume by adding robots, queues, or capacity without redesign. It depends on stateless processing and shared, externalized work items.

A committed performance target such as turnaround time or success rate for a process. Architects translate SLAs into monitoring thresholds, alerting, and capacity plans.

The instrumentation that tracks robot health, throughput, and failure rates and notifies support when thresholds are crossed. It converts silent failures into visible incidents.

A chronological record of what the automation did, when, with which data, and under whose authority. It supports compliance reviews, root-cause analysis, and dispute resolution.

Protecting credentials, personal data, and business records handled by robots through encryption, least privilege, and secure storage. Architects must ensure secrets are never hard-coded in automation logic.

The controlled storage, rotation, and assignment of the usernames and passwords robots use to sign into applications. Central vaults and role-based access prevent exposure and shared-account risk.

Rules that determine which people and robots may view or change systems, data, and automation assets. Role-based permissions limit blast radius and satisfy audit expectations.

Adherence to laws and industry rules governing data handling, records retention, and automated decisions. Architects must confirm that automation does not bypass required human oversight or reporting.

The written blueprint describing scope, process flow, system interactions, data handling, and exception strategy for an automation. It is the reference for builders, testers, and approvers.

A structured examination of a design or automation by another qualified architect or developer before release. It catches logic gaps, security issues, and maintainability problems early.

Business-led validation that the automation performs the process correctly on realistic cases. It confirms requirements are met and produces sign-off before production deployment.

The degree to which test cases exercise paths, rules, and exceptions in an automation. Architects target coverage of every decision branch and known failure mode, not just the happy path.

The defined route and owner for cases a robot cannot complete, including what information is passed along. Clear escalation prevents work from silently stalling in a queue.

A disciplined investigation to find why a failure occurred rather than only where it appeared. Architects use it to fix design weaknesses instead of repeatedly patching symptoms.