Pega CPBA common mistakes
Pega CPBA · Understand the traps and how to avoid them.
Treating the Pega Express delivery phases as a single waterfall, and answering questions as if all requirements must be gathered and signed off before any case type is built.
Candidates map the seven-phase Pega Express lifecycle onto traditional SDLC habits, so they assume design must be complete before configuration starts, which contradicts the methodology's emphasis on early, iterative delivery of a working case type.
What to do instead
Learn the Pega Express phases as an iterative, incremental flow in which a Minimum Lovable Product is defined early and the application is built and demonstrated in short increments. For any scenario question, ask what the team should do next to deliver usable functionality fastest, not what document must be finished first.
Confusing the roles in the delivery team, for example assigning backlog prioritisation to the System Architect or solution design decisions to the Business Architect.
The role names sound interchangeable and candidates study them as a list of titles rather than as a set of decision rights tied to specific artefacts.
What to do instead
Build a two-column table pairing each role with the artefacts and decisions it owns: Business Architect owns the case lifecycle and business context, System Architect owns the application structure and technical standards, and the Product Owner owns the backlog and priority. Then practise sorting scenario statements into those columns until the mapping is automatic.
Modelling a multi-actor business process as a single case type with many statuses, instead of splitting it into a primary case and child cases for the sub-processes.
Candidates think in terms of process flow rather than case hierarchy, so they try to express parallel work, different owners, and independent lifecycles through status values on one case.
What to do instead
Whenever a scenario mentions separate workstreams, distinct owners, or sub-work that can complete on its own schedule, default to a parent case with child case types. Reserve statuses for progress within one case's lifecycle. Practise by taking a described scenario and drawing the case type hierarchy before considering statuses at all.
Assuming a stage transition happens automatically when the last process in a stage finishes, without checking how the stage is configured to exit.
The stage shape in the case lifecycle designer visually suggests sequential flow, and candidates generalise from simple linear examples where the default behaviour happens to work.
What to do instead
Memorise that stage transitions are driven by explicit transition conditions or by a user action, and that a stage can be configured to wait for all processes or to advance on a condition. When a question asks why a case is stuck in a stage, check the transition configuration and the process completion state before anything else.
Choosing a data page when the requirement calls for a report definition or vice versa, and misjudging when a data transform should be used instead of a data page.
All three are ways of getting or shaping data, and candidates learn their definitions in isolation without a decision rule for picking between them.
What to do instead
Adopt a simple decision test: if the need is to display or export a list of cases matching criteria, it is a report definition; if it is to load reference data for reuse across the application, it is a data page; if it is to map or default values between structures, it is a data transform. Apply this test to every data question before looking at the answer options.
Assuming a clipboard data page always holds fresh values, and failing to recognise when stale cached data explains a described symptom.
Candidates treat data pages as live queries, overlooking that a data page is loaded once and reused until its scope or refresh settings cause a reload.
What to do instead
Learn the data page scopes and refresh strategies, and link them to symptoms: a user seeing values that another user changed is a caching symptom and points to scope or refresh configuration. For scenario questions, first ask who should share the data and how often it changes, then choose the scope.
Treating access control as a single setting, and answering questions as if a role or an access group alone determines what a user can do.
The layered model of access group, role, and privilege is easy to read as redundant, so candidates collapse it into one concept and miss the layer a question is actually testing.
What to do instead
Draw the model explicitly: an access group binds an application, a ruleset stack, and roles; roles carry privileges and access-of-role rules; attribute-based access conditions refine them. For each security question, identify which layer the scenario is changing, then reason about the effect at that layer only.
Designing a screen by listing every field from the data model, rather than deciding what the user needs at that step and which fields belong in the flow.
Candidates equate completeness with quality, so they build forms from the data structure and lose marks on questions about progressive disclosure and task focus.
What to do instead
For any UI scenario, start from the user's goal at that step and include only the fields needed to complete it, deferring the rest to later steps or a review screen. Practise by taking a data model and writing a one-sentence justification for each field you keep on a given screen.
Confusing what belongs in a ruleset versus a ruleset version versus an application, and placing reusable enterprise rules in the wrong layer.
The three layers look similar in the designer, and candidates learn them as storage locations rather than as a governance hierarchy with different change and reuse characteristics.
What to do instead
Learn the layers by their purpose: rulesets group related rules and define versioning, ruleset versions are the unit of deployment and locking, and the application assembles rulesets into a built-on hierarchy. For placement questions, ask who else needs the rule and how often it changes; reusable, slowly changing rules belong lower in the hierarchy.
Ignoring reporting and mobility implications until after the case design is fixed, then answering questions as if reports and mobile access can be added without affecting the model.
Candidates study reporting and mobility as separate late-stage topics, so they do not connect choices about case data, statuses, and assignments back to reportability and offline or responsive use.
What to do instead
When reviewing any case design, ask two follow-up questions: which fields will users need to report on, and which tasks must work on a small screen or offline. Ensure the data needed for reporting is captured as case properties rather than buried in text, and that assignment shapes suit mobile task lists. Treat these as design constraints, not afterthoughts.