Pega Primary Path (Happy Path) & Alternate Stages Guide
This is Module 3 of the Pega Certification Course (PCSA). It builds on Module 2: Case Design — Stages, Processes and Steps, so read that one first if you haven’t.
The happy path: designing it first
The primary path — the happy path — is the sequence of primary stages a case follows when everything goes smoothly: application submitted, reviewed, approved, fulfilled, done. It’s the route the majority of cases actually take, and it’s the first thing you should design when building a new case type.
The reason to design it first isn’t just convenience. A case type with a clear happy path is easy to read, easy to demo, and easy to explain to business stakeholders — which matters because in App Studio, the case life cycle view is the specification most people will look at. Pile exception handling on top of an undesigned happy path and you end up with a life cycle nobody can follow at a glance, including future-you.
In practice, that means: sketch the primary stages as short, business-meaningful phases (Submit → Review → Approve → Fulfill), get each one running end to end with real steps, and resist the urge to handle every “what if” while you’re still laying out the main sequence.
Spotting exceptions: what becomes an alternate stage
Once the happy path works, go back through the same requirements looking for anything that isn’t part of it. Requirements language is a good signal — words like reject, escalate, cancel, return, appeal, or suspend almost always describe a minority path, not the main one. Each of those is a candidate for an alternate stage.
The distinction that matters for the exam: primary stages are built to run for most cases, in a fixed order, with automatic advancement between them. Alternate stages group the exception and ad-hoc work that doesn’t fit that mold — they don’t have a fixed “next stage,” and a case only enters one when something specific triggers it.
A worked example: an Expense Report case type might have primary stages Submit → Manager Review → Reimburse. A manager rejecting the report doesn’t belong on that line — it becomes an alternate stage named Rejected, with its own process for notifying the employee and letting them revise and resubmit.
Configuring alternate stages in App Studio
Alternate stages aren’t created the same way as primary stages. Open your case type in App Studio, and from the Actions menu choose Configure Alternate Stages. This opens a lane below your primary stages where you add and name each one — for the expense example, you’d add Rejected here, not on the main stage row.
Once created, an alternate stage gets its own process, built the same way as any primary-stage process: drag in Collect information, Automation, Decision, or Subprocess steps as needed.
How a case moves into (and out of) an alternate stage
Because alternate stages sit outside the fixed sequence, a case can’t drift into one on its own — something has to move it there explicitly. That’s the job of the Change Stage automation step, which you place at the point in a primary stage’s process where the exception can occur (for instance, a Decision step after the manager’s approval action, branching to a Change Stage step when the outcome is “reject”).
Change Stage works the same way moving in either direction: into an alternate stage, or back onto the primary path once the exception is resolved. Either way, the destination stage restarts from its first step — there’s no “resume where the case last was.” Designing the target process with that in mind (idempotent, safe to run from the top) avoids surprises.
Reaching resolution: how a case ends
A case’s progress lives in a standard property, pyStatusWork, and completing the steps in the final stage of a case’s path — usually the last primary stage — moves that status to a resolved value such as Resolved-Completed. Under the hood, best practice is to let Pega’s built-in resolution actions (rather than a manual property-set) change pyStatusWork, since other logic in the case — reporting, SLAs, parent/child case updates — depends on it transitioning through the normal path rather than being overwritten directly.
Alternate stages can lead to resolution too. A Rejected stage might end the case as Resolved-Rejected instead of looping it back — the right choice depends on whether the business considers a rejection “done” or “needs another attempt.”
Hands-on: building an alternate stage
In App Studio, on a case type with a working primary path:
- From the Actions menu, select Configure Alternate Stages and add one (e.g., Cancelled).
- Build its process: a Collect information step to capture a cancellation reason, then an Automation step to notify the requester.
- Go back to the primary stage where cancellation can happen. Add a Decision step, and on the branch for “cancel,” add a Change Stage automation targeting your new alternate stage.
- Save, run the case, and trigger the path that leads to cancellation — confirm the case actually lands on the alternate stage’s first step.
Key takeaways
- The primary path (happy path) is the sequence of primary stages most cases follow; design and test it before adding exception handling.
- Requirements language like reject, escalate, cancel, return, appeal signals a candidate for an alternate stage, not a primary one.
- Add alternate stages via Actions > Configure Alternate Stages in App Studio — they live in a separate lane below the primary stages.
- A Change Stage automation step is what moves a case into or out of an alternate stage; the destination stage always restarts from its first step.
- A case’s status lives in pyStatusWork; reaching the end of a path typically resolves it (e.g., Resolved-Completed), and that should happen through Pega’s standard resolution actions, not a manual property edit.
Next up: Module 4 — Routing: Worklists, Work Queues and Assignments. Return to the full course roadmap any time.
Reminder: this course explains the concepts; for hands-on missions and the definitive, always-current material, use the official Pega Academy.
Frequently Asked Questions
What is the primary path (happy path) in Pega?
The primary path, often called the happy path, is the sequence of primary stages a case follows when nothing goes wrong — the ideal, most common route from creation to resolution. Pega automatically advances a case from one primary stage to the next once all steps in the current stage finish.
How do you decide what becomes an alternate stage?
Look at the business requirements for language like reject, escalate, cancel, return, or appeal — anything that describes work happening outside the normal sequence, for a minority of cases. Each of those exceptions is a candidate for its own alternate stage, kept separate from the primary path so the happy path stays easy to read.
How do you add an alternate stage in App Studio?
Open the case type, then from the Actions menu choose Configure Alternate Stages. This reveals a lane below the primary stages where you can add and name each alternate stage, then build its process the same way you would for a primary stage.
Does a case automatically resolve when the last primary stage finishes?
Typically yes — completing the steps in the final stage moves the case's status (the pyStatusWork property) to a resolved status such as Resolved-Completed. Best practice is to let Pega's built-in resolution actions set that status rather than editing pyStatusWork directly, since other case logic depends on it changing through the standard path.