Pega Robotics System Architect (CPRSA) common mistakes
Pega Robotics System Architect (CPRSA) · Understand the traps and how to avoid them.
Treating the exam as a pure Pega Robot Studio coding test and spending study time memorizing property names, method signatures, and .NET API details instead of practising how to decompose a business process into automation stages, queues, and exception paths.
Candidates arrive from a developer background where tool syntax feels like the hard part, and vendor training material is full of Studio screenshots, so they over-index on product mechanics. The CPRSA blueprint weights business process expertise and problem solving heavily, and scenario items ask what the automation should do and why, not which button to press.
What to do instead
Rebuild study around process artefacts: for five common back-office processes (claims intake, invoice matching, customer onboarding, order entry, HR record updates), write a one-page design that names the happy path, the decision points, the data each step needs, the exception taxonomy, and the human handoff points. Then map each design to Studio constructs only after the process logic is settled. Time-box tool study to the constructs that appear in those designs.
Answering collaboration and stakeholder questions with a generic 'communicate regularly and document everything' response instead of naming concrete artefacts, cadences, and owners (for example, a process definition workshop with the business owner, an automation readiness checklist signed off before build, a weekly triage of failed transactions with the operations lead).
Collaboration items are written as short scenario stems and candidates default to soft-skill platitudes because they have never had to justify a RPA delivery model. Scored options reward specificity: who is consulted, what is produced, and when. Generic answers are usually the distractors.
What to do instead
Prepare a one-page RPA delivery model: discovery workshop outputs, the automation candidate scorecard, the design authority review gate, the UAT sign-off owner, and the production support escalation path. For each, be able to state the artefact produced and the decision it enables. Practise rewriting any vague answer into one that names a role, a document, and a checkpoint.
Designing solutions that automate a broken or undocumented process exactly as described by one user, rather than validating the process with the business owner and checking volume, variability, and exception rate before committing to automation.
The exam scenario often presents a single stakeholder request, and candidates take it at face value because that mirrors how tickets arrive in real projects. The correct answer usually involves a discovery step: confirm the process is stable, standardised, and high-volume before building. Skipping this is the classic automation-candidate error.
What to do instead
For every practice scenario, run a three-question screen before designing: is the process standardised and documented, is the volume and frequency worth the build, and is the exception rate low enough to automate the happy path? Learn the standard suitability criteria (rule-based, repetitive, digital input, stable interface) and be ready to recommend process re-engineering or a different solution when they fail.
Ignoring non-functional requirements in design answers: never addressing credential and secret handling, audit logging, data retention, segregation of duties, or how the robot is identified to downstream systems.
Candidates focus on functional flow because that is what demos show. Security and audit questions are embedded inside larger scenario items, so the omission is invisible until the answer is scored. Many candidates also assume the platform handles it automatically, which is only partly true.
What to do instead
Add a standing non-functional checklist to every design: where credentials are stored and rotated, what is logged per transaction and for how long, which system account the robot uses, how exceptions are evidenced for audit, and who can change the automation in production. Practise attaching at least two of these to any design answer so the habit becomes automatic.
Choosing 'retry the transaction' as the default exception strategy for every failure, instead of classifying exceptions (business exception, system exception, transient vs persistent) and routing each to the right handler.
Retry is the first tool developers learn and it feels safe. Exam scenarios deliberately include business exceptions such as invalid customer data, where retrying is wrong and the correct action is to route to a work queue or a human with the reason recorded. Candidates who do not separate exception types default to retry and lose the item.
What to do instead
Build a decision table for exception handling: business rule violation, application unavailable, data mismatch, and unexpected error, each with the correct action (stop and route, retry with backoff and cap, correct and continue, escalate). Practise reading a scenario and naming the exception class before choosing the response. Know why retrying a business exception wastes capacity and hides defects.
Designing a monolithic automation that performs the whole process in one long-running flow, rather than decomposing it into reusable, independently testable stages coordinated through a work queue or case structure.
End-to-end flows are easier to demo and match how candidates think about a task. Exam items test resilience and maintainability, where a failure late in a monolith forces a full restart and blocks scaling. Candidates miss that decomposition is what enables partial recovery and parallel processing.
What to do instead
Practise decomposing two processes into stages with explicit inputs, outputs, and failure semantics, and be able to justify each boundary in terms of restart cost, reuse, and ownership. Learn the trade-off: finer decomposition adds coordination overhead, so group steps that must be atomic. Be ready to explain how a queue-based design recovers from a mid-process failure without redoing completed work.
Assuming the automation can rely on the same UI path every run: fixed screen coordinates, fixed wait times, and no handling for pop-ups, slow responses, session timeouts, or application version changes.
Studio records a happy path that works in a controlled environment, and candidates extrapolate that reliability is inherent. Exam scenarios introduce latency, unexpected dialogs, and interface changes, and the correct answers involve explicit waits on events, robust element identification, and recovery logic.
What to do instead
For each practice design, list the top five runtime variations the robot will meet and specify the detection and recovery for each: wait on a specific UI event rather than a fixed delay, match elements on stable attributes rather than position, handle session expiry by re-authenticating and resuming, and define a screenshot-and-escalate path for unknown dialogs. Be able to explain why fixed sleeps are both slow and unreliable.
Treating the human-in-the-loop boundary as an afterthought: automating steps that require judgement or customer interaction, or leaving a handoff with no defined data contract, status, or SLA.
Candidates optimise for maximum automation percentage and treat human steps as failures. Exam items reward correct allocation of work between robot and person, and penalise designs where a human receives an incomplete case with no context or where a judgement call is forced into brittle rules.
What to do instead
Practise drawing the human/robot boundary explicitly: which decisions need judgement, empathy, or authority, and what the robot must pass to the human (case reference, extracted data, reason for escalation, suggested action). Define the return path when the human completes the step. Be able to justify why a 70 percent automated process with clean handoffs can outperform a 95 percent automated one with frequent silent failures.
Skipping measurement and benefit realisation: designing the automation without defining baseline effort, cycle time, success rate, and the operational dashboards that prove value after go-live.
Candidates equate a working robot with a successful project. Exam items in the business process domain ask how success will be evidenced and how the business will know the investment paid back, and answers that stop at 'the robot runs' miss the point.
What to do instead
For each practice scenario, state the baseline metrics before automation, the target metrics, the measurement source, and the review cadence with the business owner. Include operational metrics such as straight-through processing rate, exception rate by category, and average handling time for escalated cases. Be ready to explain how you would detect that an automation is silently degrading in production.
Managing the exam by reading scenario stems quickly and selecting the first plausible option, without eliminating distractors that are technically correct but operationally wrong in the stated context (for example, a valid design that ignores the stated volume, regulatory constraint, or existing system limitation).
Scenario items are long and time pressure builds, so candidates pattern-match keywords. Distractors are written to be plausible precisely because they are valid in other contexts; the differentiator is a constraint buried in the stem, such as a legacy system with no API or a compliance requirement for dual approval.
What to do instead
Adopt a fixed reading routine: extract the constraint sentence first, restate the actual question in your own words, then eliminate options that violate the constraint before comparing the survivors. Flag and return to any item where two options seem equally good, and practise with timed sets so the routine holds under pressure. Review every wrong answer to identify whether the miss was knowledge or constraint-reading.