Pega Certified System Architect common mistakes
Pega Certified System Architect · Understand the traps and how to avoid them.
When a scenario says 'Region A and Region B need slightly different approval logic,' the candidate picks case type inheritance and describes copying or re-creating the parent's stages, processes, and properties in the child case type instead of reusing them.
Inheritance and circumstancing both produce 'the same case with a variation,' so the candidate pattern-matches on the phrase 'different logic' without checking whether the difference is a durable subtype or a runtime property-driven variation, and often forgets inheritance runs one direction (child inherits from parent) and single-parent only.
What to do instead
Apply a two-question test before answering: (1) Is the variation driven by a data value at runtime (region, product, channel)? If yes, circumstancing. (2) Is it a durable specialization that adds new stages/properties and is modelled as its own case type? Then it is inheritance, and the child inherits parent stages and processes without re-declaring them. Say the direction out loud: the parent never inherits from the child.
The candidate attaches an SLA (goal/deadline/passed deadline) to an assignment or a stage when the stated business requirement is a time limit on the whole case, or conversely puts a case-type-level SLA on a requirement that only concerns one step.
All three SLA placements are configured through similar-looking UI and all read as 'a time limit,' so the candidate answers on the word 'deadline' rather than on the scope of work the timer should govern.
What to do instead
Before choosing, restate the requirement as a subject: if the subject is 'the case' (e.g., the loan must be decided in 10 business days), the service level belongs to the case type; if the subject is 'this task' (the reviewer must respond in 2 days), it belongs to the assignment; if the subject is 'this phase of the lifecycle,' the stage. Assignment-level timers will not fire the case-wide escalation you were asked for.
For every 'send the work to a team' scenario the candidate answers 'route to workbasket,' and never distinguishes worklist, workbasket, work group, and skill-based routing, or assumes an assignment routed to a workbasket is owned by a person.
Workbasket, worklist, and work group sound interchangeable in ordinary English, and the candidate has not memorized that a workbasket holds unowned work that someone must pull, while a work group is the team container a manager can see into, and skill-based routing picks a qualified user.
What to do instead
Memorize the ownership axis: route to worklist = a specific operator owns it; route to workbasket = unowned queue, no one owns it until someone picks it up; route to work group = goes to the team's default queue; skill-based routing = matched to a user by configured skills and availability. Answer by asking 'who owns the assignment the instant routing completes?'
The candidate selects 'requestor' or 'thread' scope for a data page that holds slow-changing reference data (country codes, product catalog) that every user on the server should share, then wonders why the exam answer says the data is reloaded per user or per case.
Scope names are learned as a list to memorize rather than as a sharing/lifetime trade-off, and the candidate does not connect scope to how often the source is hit and who must see the same copy.
What to do instead
Decide scope by answering two questions: how volatile is the data, and how widely must one copy be shared? Thread scope for case-specific edits that must not leak between cases; requestor scope for data tied to a user's session; node scope for shared reference data all requestors on that node may reuse; application scope for data that must be identical across the whole application. Reference/lookup data that changes rarely is the classic node-scope answer.
The candidate expects a change made to a page to be written back to the data source by a Data Transform, or treats a plain (non-savable) data page as if edits to it would persist.
Data Transform and Data Page are both 'data' features and both appear wherever sources and mappings are configured, so the candidate conflates copying/mapping data with persisting it, and does not notice the savable flag on the data page definition.
What to do instead
Separate the three verbs: a Data Transform maps/copies values between pages and never saves; a data page is a cache with a defined source and scope and is read-only unless it is explicitly configured as savable; saving to the system of record needs a savable data page or an explicit save/connector call. When a question mentions 'updates must be written back,' eliminate every option that only maps or only caches.
The candidate gives reusable business data its own concrete class when the requirement describes a structure that only exists inside one case (and vice versa), or fails to recognise that an embedded page is not a standalone data class.
Class names like Data- and Embed- look like naming conventions rather than a modelling decision, so the candidate picks based on which one 'sounds more organized' instead of on reuse and ownership.
What to do instead
Ask 'does this data have an independent life outside this case?' If yes, it is a Data- class with its own keys and can be referenced and reused. If it is a structure owned by and meaningful only within the case (an address block on a case, a line item), model it as an embedded page/property in the case's class rather than a separate Data- class.
Asked to change the layout a user sees when working a single assignment, the candidate says to modify the harness, and when asked where a case-level header/navigation lives, says to modify the section used by that assignment.
Harness, section, and flow action are all 'the screen' to a candidate who has only built screens in one layer, so the three names are stored as synonyms instead of as container/hierarchy.
What to do instead
Anchor the hierarchy: the harness is the outer container that frames the case (header, navigation, overall context); the section is the reusable content block; the flow action is the configuration the assignment shape invokes, and it determines which section renders for that task. A requirement scoped to 'one task' points at the section/flow action; a requirement scoped to 'every screen of this case type' points at the harness.
The candidate makes a field conditionally mandatory by writing an edit validate rule, or makes a field read-only by adding a validation rule, instead of using the form's required/disable/visibility conditions.
Validation and presentation conditions are both 'rules about a field,' and the candidate has not separated format checking from presence/state control, so any requirement containing 'must' or 'cannot' gets routed to validation.
What to do instead
Categorize the requirement first: format/content checking (a value must look like a valid postal code) is edit validate; whether the field is present, mandatory, enabled, or editable is controlled by the form's required setting, required conditions, and visibility/disable conditions. If the requirement is about what the user is allowed to do on the screen, the answer is a presentation condition, not a validation rule.
The candidate grants a privilege to give a role the ability to view and update a class of case data, or creates an access role expecting it to restrict which rows of a data page a user sees at runtime.
Privilege, access role, and access control policy all appear under the security umbrella, and the candidate maps them by name familiarity rather than by what each one governs: class-level CRUD, a specific action, or row-level filtering.
What to do instead
Use a three-way routing of requirements: 'can this role read/write/delete this class?' is answered by access of role to object; 'can this user run this one action or flow action?' is a privilege attached to the action; 'which records can this user see, filtered by their own attributes?' is attribute-based access control through access control policies and conditions. If the requirement mentions filtering rows, privileges and ARO will not satisfy it.
The candidate expects a change to an operator's access group (or a change to the role/privilege behind an access group) to apply immediately to a user who is already logged in and has the application open.
Candidates treat access group assignment like a profile field that is read live on each request, and have not learned that access group and its resolved roles are established at login, so an existing session keeps the resolved security context.
What to do instead
Recall the rule that the security context is resolved at authentication: to see the effect of an access group change, the operator must log in again (or the session must be re-established). When a question asks 'why does the user still see the old behaviour after the change?' the expected answer is the stale session, not a missing privilege.