Pega LSA common mistakes
Pega LSA · Understand the traps and how to avoid them.
Treating the written Architecture exam as a vocabulary recall test and memorising definitions of concepts like Case Type, Data Page scope, or Class hierarchy without being able to reason about trade-offs between them in a scenario.
Most study material for Pega certification is definition-heavy, so candidates rehearse glossaries and pass practice quizzes that reward recall, then meet scenario items that ask which design is preferable and why, and default to the most familiar term rather than the best fit.
What to do instead
Convert every concept you study into a decision rule: for each architecture concept write one sentence on when you would choose it, one on when you would not, and one concrete consequence of getting it wrong (for example, the effect of a data page scope on memory and staleness across requestors). Practise by reading a scenario stem, writing your chosen design and a two-line justification before looking at options, then check whether your justification actually discriminates between the options offered.
Designing the solution around the happy path only, so the case lifecycle, statuses, and stage transitions are built for the primary flow and then patched with ad-hoc when rules or extra statuses when a secondary flow appears.
Candidates build the demo scenario first under time pressure and treat alternate and exception paths as later work; the case type then accretes conditional transitions that are hard to reason about, and the design becomes brittle when the exam's secondary process is exercised.
What to do instead
Before configuring, enumerate the lifecycle on paper: every stage, the processes inside each, the alternate stages, and the resolution statuses each process can reach. Model secondary paths as first-class alternate stages or optional processes rather than conditional jumps, and validate by walking each enumerated path against the configuration before moving to the next area.
Putting reusable business logic directly in the case type's flow or UI section instead of in a rule that can be reused and overridden, so the same calculation or validation is duplicated across processes and diverges.
The fastest way to make one screen behave correctly is to add the logic where the screen is; candidates optimise locally and only discover the duplication when a second channel or process needs the same behaviour and the two copies disagree.
What to do instead
For each piece of logic, ask whether more than one process, channel, or case type could need it; if so, place it in a named, purpose-built rule (a decision rule, a data transform, or a validation rule) and call it from the flow or UI. Keep the flow and section thin: they orchestrate and display, they do not compute. Review your configuration at the end and list every place a business rule appears twice.
Choosing data page scope by habit rather than by lifecycle, for example making a reference data page requestor-scoped so it is reloaded on every request, or making it node-scoped when the data must reflect a per-user security context.
Scope options look interchangeable in a configuration form, and candidates pick the default or the one that made a previous exercise work; the consequences (repeated loads, stale data, cross-user data leakage) only show up under concurrency or when the exam checks refresh behaviour.
What to do instead
For every data page, write down three facts first: how often the source changes, whether the content depends on the operator or requestor, and whether it is safe to share across users. Derive the scope from those facts and state the refresh strategy explicitly (load once, reload on a condition, or refresh at a defined point). Sanity-check any page holding user-specific data is not shared beyond the requestor.
Building the integration as a direct connector call from the flow, with no simulation, error handling, or mapping layer, so the hands-on environment's unavailable or slow service breaks the case and the candidate cannot demonstrate the process at all.
Candidates want to show the end-to-end path working and wire the connector straight into the process; when the external system is stubbed, rate-limited, or returns an unexpected shape, the case errors and time is lost debugging infrastructure instead of design.
What to do instead
Always separate the integration contract from the caller: define the request and response data shapes, map them in a dedicated data transform, and place the call behind a data page or service rule that can be simulated. Configure explicit error handling for timeout, system error, and mapping failure with a defined case outcome for each, and test with a simulated response before pointing at the real endpoint.
Ignoring the class structure and inheritance model, placing case types and data types at whatever class the wizard defaults to, so rules cannot be specialised or reused and the design has no clean separation between work, data, and integration layers.
The create-case wizard produces a working case quickly and the class it lands in is rarely inspected; candidates focus on visible behaviour and only feel the cost when they need to override behaviour for a variant case type or share rules across case types.
What to do instead
Sketch the class hierarchy before building: a work layer for case types with a common parent for shared rules, a data layer for data types, and an integration layer for connectors. Place each rule at the most general class where it is universally true and specialise downward only where behaviour genuinely differs. Verify by naming two rules you expect to inherit and confirming they resolve from the parent.
Skipping the specification step and starting to configure immediately, so the case type, data model, and user interface are built before the requirements are understood and large parts are rebuilt when a missed requirement surfaces.
Time pressure on the hands-on exam rewards visible progress, and configuration feels productive; candidates equate typing in the designer with making progress and defer the thinking, which then happens twice.
What to do instead
Spend a fixed, deliberate block at the start producing a one-page specification: actors, case types, stages, data objects and their sources, integrations, and the reports or views required. Keep it visible and tick items off as you configure. When a new requirement appears, add it to the page and decide whether it changes the model before touching the designer.
Configuring security late, treating access control as a final step, so operators, access groups, and roles are set up to make the demo work rather than to reflect the intended authorisation model, and privilege escalation or missing access then blocks testing.
The default operator and access group are sufficient to build and test as a single user, so security never forces a decision until a second persona is needed; by then the access model is implicit in whatever was configured for convenience.
What to do instead
Define the personas and their access groups at the start of the build and test each significant step as the intended persona, not as the developer. Set access roles so that only the actions each persona needs are permitted, and confirm that a restricted persona genuinely cannot reach the privileged action. Treat any access change as a design change that must be re-tested across personas.
Leaving the user interface as a flat form of every property on the case type, with no views or sections aligned to the task, so the flow works but the case is hard to use and the UI does not reflect the case lifecycle.
Dragging every property onto one section is the quickest way to prove the data model works, and candidates treat UI as cosmetic relative to process logic; the result passes a functional check but fails the design intent the exam is assessing.
What to do instead
Design each assignment around the decision the user is making: show only the fields needed for that step, group related information, and use read-only presentation for context. Confirm every view maps to a stage or process in your specification, and remove any field that no step requires.
Not rehearsing under exam conditions, so the candidate knows the material but runs out of time on the hands-on build or misreads scenario stems on the written exam because they have never practised at pace.
Study is usually done untimed and open-book, which hides both pacing problems and the habit of over-researching a single question; the exam then converts a knowledge gap into a time-management failure.
What to do instead
Run at least two full timed simulations per domain: for the written exam, answer a set of scenario items in a strict per-question budget and review only after the set is complete; for the hands-on exam, build a complete small case type end to end against a clock, then review what you skipped. Track where time went and pre-decide a cut-off rule for when to move on from a stuck item.