Create your own requirements and example data. Do not copy, upload or request feedback on Pega's confidential Application Design & Build assessment scenario or submission. Pega's official rules govern that work.
Begin with a brief you can test
Imagine an internal equipment-request application for a company with several departments. An employee requests a laptop or accessory, a manager approves exceptions, an inventory service reports availability, and fulfilment staff reserve and deliver the item. An auditor later needs to understand who made each decision and why.
Write the request in business language before configuring rules. For example: “A standard accessory below the approval threshold can proceed without manager review; non-standard or higher-cost items require approval.” That sentence is still incomplete until you define the threshold, currency, catalogue ownership and what happens when the manager is unavailable.
- Outcome: the requester sees a truthful status from submission through fulfilment or rejection.
- Actors: requester, manager, inventory/fulfilment staff and an authorised auditor.
- Constraints: stock belongs to an external inventory system; a failed lookup is not the same as “out of stock.”
- Acceptance criteria: each branch has an observable result, an owner and a test that can prove it.
Use fictional people, departments and stock records. The value is in your reasoning, not in reproducing an assessment prompt.
Model the case, data and personas together
A sensible starting point is one Equipment Request case with submit, review, reserve and fulfil stages. An approval step is conditional on the documented policy. Do not create a child case merely because a diagram looks more sophisticated: a child becomes useful when part of the work genuinely needs its own lifecycle, ownership, deadline or reporting.
Case and assignments
Define what starts the request, who owns each assignment, when a decision is final and how the requester learns the outcome. Trace cancellation or rejection as carefully as successful fulfilment.
Data and system of record
Separate request facts from catalogue reference data and stock data. Decide which facts must be persisted on the case for an audit and which should be refreshed from the owning system.
Personas and views
Show requesters only their requests, managers the approval context they need, fulfilment staff allocation actions and auditors read-only evidence. Check views and actions—not only navigation labels—against those boundaries.
Keep the model adaptable: if fulfilment later becomes a separate operational service, document why you would split it and how the parent request would learn its status. Explain the tradeoff rather than presenting one model as universally correct.
Use Blueprint as a proposal to review, not a design verdict
Pega Academy describes Blueprint as a way to propose case types, lifecycles, data models and personas. In an LSA practice exercise, compare any generated proposal with the brief. Would a “Laptop Request” case type duplicate a general equipment request? Did it invent data fields that no process needs? Did it miss an external stock system or a persona who approves exceptions?
Record each correction and why it helps the business outcome. If you use a Blueprint export in your own practice environment, validate its imported structure before adding logic. Pega Academy's current LSA learning mission also covers planning and design, implementation and deployment, and Constellation adoption; use those official learning materials to check the scope of your review.
Keep a compact design decision record
A decision record should make a choice reviewable. State the question, alternatives, reason for choosing one, and the evidence that would show whether it works. The following is an example for this fictional application, not an official Pega design answer.
| Design question | Alternatives | Provisional decision and reason | How to validate |
|---|---|---|---|
| How should fulfilment be represented? | One Request case with a fulfilment stage, or a Request parent with separate Fulfilment cases. | Begin with one case while the work has one owner and one lifecycle. Introduce a child case only if fulfilment needs independent ownership, timing or reporting. | Walk through single-item and multi-item requests; confirm who owns each assignment and which status a requester sees. |
| Where does inventory truth live? | Copy a stock count into the case, or query and reserve through the inventory system. | Treat the inventory service as the system of record. Keep only the response and reservation reference needed for the case decision and audit trail. | Change stock between approval and fulfilment; verify the application does not rely on a stale earlier snapshot. |
| When is approval required? | Approve every item, or route high-cost and exceptional requests to a manager. | Express a testable policy: a manager reviews requests above a stated threshold or outside the standard catalogue. Do not bury policy in a screen-only condition. | Test both sides of the threshold, a missing manager, and a requester attempting to approve their own case. |
| What happens when the stock service fails? | Treat a timeout as unavailable stock, retry indefinitely, or pause for a controlled recovery path. | Distinguish 'out of stock' from 'status unknown'. Record a bounded recovery action and avoid duplicate reservations after a retry. | Simulate timeout before and after reservation and check that a repeated action cannot silently allocate twice. |
“Provisional” matters: a good LSA changes a decision when a new requirement, load profile or governance constraint changes the evidence. Keep the date and owner of the decision in a real project record; this example does not pretend to represent a client project.
Draw the inventory boundary and its failure paths
The equipment application owns the request workflow; the inventory system owns stock and reservation truth. Draw that boundary before implementing an API call. Define a small contract: an item identifier, a quantity, a correlation or idempotency identifier, an availability result and a reservation reference. Do not assume a successful HTTP response means the physical item has been delivered.
Consider a timeout after the inventory system reserved stock but before the application received confirmation. Blindly repeating the reservation could allocate twice. Your recovery design should let an operator determine whether the first operation succeeded, then retry safely or reconcile the case. A test service can model these conditions without touching a real inventory system.
“No stock available” can lead to a backorder or alternative item. “Inventory service did not answer” requires a different status, retry policy and human visibility. Treating both as rejection hides a recoverable technical problem.
Test access rules and the audit trail, not just the happy path
Define permissions by persona and action. A requester may submit and view their own cases but must not approve a request or edit another employee's address. A manager can approve only cases assigned under the policy. Fulfilment staff can record reservation and delivery without changing the approval decision. An auditor can inspect evidence without performing work.
Test both the visible interface and direct navigation or service calls. Hiding a button is not an access-control rule. Capture a trace of who submitted, approved, reserved and closed the case, with enough detail to investigate an exception. Avoid recording unnecessary personal data or secrets in logs.
Make every important decision observable in a test
Tests should connect a requirement to an expected result. Use your own test accounts and mock service responses. The checklist below gives a practical starting set; adapt it to the policies you wrote rather than memorising a fixed script.
| Area | Activity | Expected evidence |
|---|---|---|
| Request and validation | Submit valid, missing and contradictory requester/item details. | The case begins only with required data; errors identify what to correct without exposing another employee's information. |
| Approval routing | Submit a standard request, an exception and a high-cost request. | Each follows its documented policy; only the assigned manager can decide, and self-approval is blocked. |
| Inventory integration | Return available, unavailable, timeout and malformed responses from a test service. | Availability and service failure remain distinct; the case does not report fulfilment before reservation is confirmed. |
| Retry and duplicate protection | Repeat the reserve command after a slow response and submit the same action twice. | A single request cannot create multiple reservations; the recovery state remains understandable to an operator. |
| Role-based access | Try requester, approver, inventory staff and auditor accounts on each assignment and data view. | Each role sees only permitted actions and fields; direct URL or API access does not bypass the rule. |
| Audit and support | Trace creation, decision, reservation, exception and closure. | An authorised reviewer can reconstruct the decision and the integration outcome without logging unnecessary personal data. |
| Change and regression | Change the approval threshold or add a new equipment type. | The policy is updated in one intended place and the existing request paths still pass their tests. |
| Usability and operations | Review key views with each persona and simulate a delayed background task. | The next action is clear, status is accurate and an operator can identify work that needs intervention. |
Keep screenshots or notes only for your independent exercise, with invented data. A test that passes by accident because the user has administrator privileges is not evidence that role-based access works.
Review your own output like an LSA
- Read each requirement beside the case stage, data field, access rule and test that fulfils it. Mark any gap.
- Ask another learner to challenge one design tradeoff using only your decision record—not a private assessment scenario.
- Change one policy or integration response and rerun the affected tests. Note what broke and why.
- Summarise what you would monitor or hand over to an operator after deployment.
- Compare your weak areas with the current Pega Lead System Architect mission and Architecture exam outline; use Pega Academy for official requirements.
The goal is an explainable, maintainable practice solution. Completing this exercise cannot prove assessment readiness or guarantee certification; use the current Pega Academy rules to choose your next official step.
Official references and next steps
- Pega Academy: Certified Pega Lead System Architect journey — official pathway and Application Design & Build context.
- Pega Academy: Lead System Architect mission — current architecture learning scope.
- Pega Academy: Lead System Architecture exam — public exam outline.
- Pega Academy: Blueprint for application design and development — reviewing generated cases, data and personas.
Continue your preparation
Use the practical Pega LSA study plan to organise your learning, or read the Pega LSA preparation overview for the current pathway and contact options. You can also explore the Pega certification directory; verify all official requirements with Pega Academy.
Explore Pega LSA guidance