Pega CPSSA common mistakes
Pega CPSSA · Understand the traps and how to avoid them.
Treating the position of a stage or process in the Case Lifecycle Designer as the place where the case's status is decided, and assuming the case status text is whatever stage name the designer typed.
The designer visually shows stages left to right, so candidates mentally map 'stage = status'. In practice a case's status is driven by the work status values configured on the steps and stages, and the stage labels are independent of the status shown to users. Questions that ask which status a case reports after a transition are missed because the candidate reads the diagram instead of the status configuration.
What to do instead
When revising case lifecycle topics, practise reading the case type rule's status configuration rather than the diagram: for each step, note the work status it sets, and for each stage, note the stage-level status. Build a small table of stage to status to step mappings for one sample case type and verify it in a personal instance. On exam questions, locate the step that is executing and answer from the status assigned to that step, not from the stage name.
Designing a screen flow with a single 'Next' navigation step that collects data across several steps, then trying to save the partially completed data back to the case before the flow finishes.
Candidates reuse the habit of building one big form and assume each harness step writes to the clipboard automatically. Screen flows collect data in the flow's own context, and the case data is only committed when the flow is configured to do so, so questions about partial submission or resume-later behaviour are answered incorrectly.
What to do instead
Learn the difference between a screen flow that is embedded in a process and one that is launched as a standalone flow, and know which one persists data on each step. Practise configuring a flow with 'Start' and 'Review' steps, adding an explicit persist or 'Save for later' action, and observing what appears on the case clipboard before and after. Answer exam questions by asking where the data lives at the moment described.
Assuming that once a case moves to a later stage, the earlier stage's processes stop running and any open assignments in them are automatically withdrawn.
Linear reading of the lifecycle diagram suggests stages are sequential phases that clean up after themselves. In reality multiple stages can be active at the same time, and assignments created in an earlier stage remain open unless the design explicitly resolves or withdraws them. Candidates then pick answers that assume automatic cleanup.
What to do instead
Study the concepts of parallel stages, optional stages, and stage-level entry and exit criteria, and note that a case can have several active stages. Practise adding a second stage that runs alongside the first and observe the open assignments list. For exam questions, check whether the scenario mentions a stage transition action or a configured cleanup before assuming an assignment disappears.
Choosing a data transform as the place to enforce a business rule that must hold for every path into a case, such as 'an approval amount above a threshold requires a second approver'.
Data transforms are the most familiar tool for shaping data, so candidates reach for them whenever data must change. But a data transform runs only when it is invoked, so a rule placed there can be bypassed by any path that does not call it, and validation placed there behaves differently from a declarative constraint.
What to do instead
Separate the tools by purpose: data transforms for mapping and defaulting, validation rules or declarative constraints for invariants, and decision rules for branching. For each 'must always be true' requirement in a practice scenario, write down which rule type enforces it and which paths could bypass it. On the exam, reject any answer that enforces a universal rule only through a transform invoked on one path.
Treating a data page as a cache that is always fresh, and answering questions about stale reference data as if the page reloads on every access.
Data pages look like ordinary clipboard pages in the UI, and candidates forget that their reload behaviour is a configuration choice. Questions about how often a lookup runs, or why a user sees outdated values, hinge on the data page's scope and refresh strategy, which the candidate never considered.
What to do instead
Memorise the data page refresh options and what each means for when the source system is called, and the difference between a page scoped to a request, a thread, or the whole application. Build a practice data page against a sample REST service, set each refresh option in turn, and log the outbound calls to see the difference. On exam questions, identify the scope first, then the refresh setting, then answer.
Assuming that deleting a property from a class removes the data from existing case instances, or that renaming a property migrates the stored values.
The class designer presents properties as a clean schema, so candidates treat edits as schema migrations. In practice stored case data keeps the old property name, and questions about what happens to in-flight cases after a model change are answered as if the change were retroactive.
What to do instead
Learn how property removal and renaming affect existing instances, and what tooling exists to map old values to new properties. In a practice application, create a case with a value, rename the property, and inspect the stored data to confirm the behaviour. For exam scenarios about model changes with live cases, answer from the persistence behaviour, not from the designer view.
Designing a section that looks correct in the preview but breaks when the same section is reused in a different context, because the layout relies on hard-coded widths or on properties that are not present in the new context.
Candidates optimise for the single screen they are building and do not test reuse. Reusable sections and harnesses are a recurring exam theme, and questions about responsive behaviour or about a section failing in another case type are missed because the candidate never considered the data context.
What to do instead
Adopt a habit of building every section against a dynamic layout with relative sizing and testing it in at least two harnesses with different data. Learn how section parameters and the page context determine which properties resolve, and practise passing a parameter into a reusable section. Exam questions about reuse should be answered by checking whether the property exists in the target context.
Confusing what a visibility condition on a layout does with what an enable condition or a required condition does, and picking an answer that hides a field when the requirement is to prevent editing.
All three are configured in similar places in the property panel, and the wording of exam scenarios is deliberately close. Candidates who have only used visibility conditions assume the other two behave the same way, then choose an option that removes the field from the form instead of locking it.
What to do instead
Write a one-line definition for each condition type and a one-line note on what the user sees when it evaluates false. Build a practice form with three fields, one per condition, and toggle each to observe the rendered result, including what happens on submit when a required condition is false. On the exam, translate the requirement into 'hidden', 'read-only', or 'cannot submit' before looking at the options.
Granting a role the access it needs by adding it to a broad access group, without checking whether an existing deny or a more specific rule will override the intended permission.
Access control is layered, and candidates reason about it as a single list of grants. When a scenario asks why a user cannot open a case type they appear to have access to, the candidate answers from the role they just added rather than from the full evaluation order.
What to do instead
Learn the order in which access is evaluated across access groups, roles, and privilege or attribute-based conditions, and note where a deny takes precedence. In a practice application, create two access groups with overlapping roles and a deny, then log in as a test user and confirm which rule wins. For exam questions, trace the specific user's access groups before judging the permission.
Assuming that authentication configuration alone secures an integration endpoint, and ignoring authorization of the calling system or the data it is allowed to see.
Security questions often describe a service that authenticates callers successfully, and candidates stop there because authentication is the visible configuration. Authorization, including which cases or properties the caller may read, is a separate design decision that the scenario is usually testing.
What to do instead
Separate authentication from authorization in your notes: who the caller is versus what the caller may do. Practise exposing a data page through a service and restricting the result set by the caller's identity, then test with two different credentials. On the exam, if the scenario says the caller authenticated but saw too much or too little, the answer concerns authorization, not credentials.