Pega Robotics System Architect (CPRSA) study plan

Map each of the three exam domains to the specific Pega Robotics Studio artifacts you already use at work, writing a one-line note on where each domain shows up in a real automation project.

Walk through the end-to-end lifecycle of a single automation (requirements intake, design, build, test, deploy, handover) and label which lifecycle stage belongs to business process expertise versus problem solving.

Draft a glossary of 20 business-process terms you would need to explain to a non-technical stakeholder, including process decomposition, exception path, business exception versus system exception, and SLA.

Identify three recurring business-process patterns in your own organization (for example approval routing, data reconciliation, or queue-based work distribution) and describe how each would be automated.

Decompose a real business process into sub-processes and decision points, then mark which steps are automatable, which need human intervention, and which should be redesigned rather than automated.

Write business exception handling requirements for that process, distinguishing business exceptions (invalid data, missing approval) from system exceptions (application crash, timeout).

Define measurable success criteria for the automation, including cycle-time reduction, error-rate targets, and volume assumptions.

Explain the difference between automating a task and automating a process, and justify which one your chosen scenario requires.

Translate your process decomposition into a design that names the Pega Robotics components involved (solution, project, automation, global container, adapter, component) without yet building them.

Identify every external system your automation must touch and record the integration method each one supports (UI adapter, database, web service, file, or queue).

List the failure modes for each integration point and propose a handling strategy for each.

Review your design against the business requirements from week 2 and flag any requirement you cannot satisfy with the components you named.

Build a small working automation in Pega Robotics Studio that exercises at least one UI adapter, one data lookup, and one decision branch.

Implement explicit error handling for at least two failure modes, using try/catch patterns and logging rather than silent failure.

Use the debugger to step through execution, set breakpoints, and inspect variable state at runtime.

Refactor the automation to move repeated logic into a reusable component or script and confirm behavior is unchanged.

Diagnose and fix three deliberately introduced defects in your week-4 automation, recording symptom, root cause, and fix for each.

Harden the automation against UI changes by making selectors and element matching more resilient, then verify by simulating an application change.

Design a test approach covering happy path, business exceptions, and system exceptions, and execute it.

Measure runtime performance and identify at least one bottleneck or inefficiency in the automation.

Prepare a deployment and handover package that a colleague could use to run and maintain the automation without your involvement.

Write operational runbook content covering how to start, monitor, restart, and troubleshoot the automation in production.

Anticipate five questions a business owner or IT operations reviewer would ask about the automation and write answers grounded in your design.

Practice explaining a technical trade-off (for example, UI automation versus API integration) to a non-technical audience in under two minutes.

Run a mock requirements workshop with a colleague acting as a business stakeholder, and produce a written requirements summary from it.

Identify and document at least three points where business expectations and technical constraints conflict, and propose a resolution for each.

Draft a status update for a non-technical sponsor that communicates progress, risks, and decisions needed without technical jargon.

Define the review and sign-off checkpoints you would use across the automation lifecycle and who participates in each.

Consolidate your notes into a single review sheet organized by the three domains, with your weakest subtopics flagged first.

Re-derive from memory the lifecycle stages, exception-handling distinctions, and component-to-requirement mapping without consulting notes, then check against your documents.

Rehearse scenario-style reasoning: for a fresh business scenario, outline requirements, design, failure handling, and stakeholder communication in outline form within a time limit.

Close remaining knowledge gaps by revisiting the two flagged subtopics with targeted study and a written self-test.