Pega Case Design: Stages, Processes & Steps (PCSA Guide)

This is Module 2 of the Pega Certification Course (PCSA). If you haven’t yet, start with Module 1: Pega Basics — this module builds directly on the stages/processes/steps vocabulary it introduced.

Pega case design: the three building blocks

In Module 1 you saw that a case type’s life cycle is made of stages, processes, and steps — and that case management is worth roughly 40% of the PCSA exam, more than any other domain. This module goes one level deeper into each of those three pieces, because Pega case design is the single skill you’ll use in nearly every hands-on exercise for the rest of this course.

Quick recap of the hierarchy, from biggest to smallest:

• Stage — a major phase of the work (e.g., Review, Approval).
• Process — a sequence of steps inside a stage, implemented under the hood as a flow rule.
• Step — a single action inside a process: a form to fill out, a decision, an automation.

Every new case type starts life with one stage already in place: a Create stage that collects whatever information is needed to open the case. Everything you add after that — Review, Approve, Fulfill, or whatever your business process calls for — builds on top of it.

Stages: the primary path

The stages you lay out left to right in App Studio’s Case Type view are called primary stages. Together they form the primary path (the “happy path”) — the sequence a case follows when nothing goes wrong.

Primary stages have one important built-in behavior: when every step in a primary stage is complete, the case automatically advances to the next primary stage. You don’t have to wire that up yourself — it’s the default. That’s what makes the primary path fast to design: you focus on describing what happens in each stage, and Pega handles moving the case forward.

Alternate stages: designing for exceptions

Real work doesn’t always follow the happy path — applications get rejected, claims get escalated, orders get cancelled. Pega handles these with alternate stages: stages that sit outside the primary path and are entered only when something deviates from the ideal flow.

You add them from Actions > Configure Alternate Stages in the Case Type view, giving each one a name (e.g., Rejected, Escalated, Cancelled). Unlike primary stages, alternate stages do not automatically advance to “the next stage” when their steps finish — there’s no fixed next stage to fall through to, since they sit off the main line. Instead, you use a Change Stage automation to move the case explicitly, either into an alternate stage or back onto the primary path. When a Change Stage step sends a case back to a primary stage, that stage restarts from its first step.

Good case design follows the same guidance from Module 1: model the primary path first, get it working end to end, and only then layer in the alternate stages for exceptions. Trying to design every edge case up front makes a case type hard to reason about.

Processes: the flows inside a stage

Inside a stage, work is organized into one or more processes. A process is a series of steps meant to run in a logical, sequential order — and under the hood, a process is a flow rule.

A stage can contain multiple processes, and not all of them have to run for every case. App Studio distinguishes:

• Starting processes — the process (or processes) that begin automatically when the case enters the stage. When you create a stage-based case type, Pega automatically adds a default starting flow (commonly named pyStartCase) to get things moving.
• Optional processes — additional processes a user can trigger from within the stage when needed, rather than something that runs every time.

This separation lets a single stage handle both “the normal thing that always happens” and “the thing that happens sometimes” without forcing every case down the same rigid path.

Steps: the building blocks of a process

A step is the smallest unit of work, and Pega gives each step type its own shape so a process flow is readable at a glance:

Step type	What it does	Shape (Process Flow view)
Collect information	Shows a form so a user can enter data	Green rectangle
Automation (e.g., Send Email, Create Case, Change Stage)	Runs automatically, no user input	Yellow rectangle
Decision	Branches the path based on a condition	Orange diamond
Subprocess (e.g., Approve/Reject)	Calls another process, reusable across stages and case types	Blue rectangle

Subprocesses are worth calling out: because they’re just another process that a parent process can call, you can build something like an Approve/Reject subprocess once and reuse it across multiple stages — or multiple case types entirely. That’s a direct application of “everything is a rule, and rules are meant to be reused.”

Hands-on: building a process

In App Studio, inside a stage:

1. Click + Process (or edit the default starting process) to open it in the flow view.
2. Drag in a Collect information step and attach a form/view to it.
3. Add a Decision step if the next action depends on what the user entered (e.g., amount over a threshold).
4. Add an Automation step — for example, Change Stage — to explicitly move the case forward or into an alternate stage.
5. Save, then Run the case again to walk through the new process live.

Building this by hand, one process at a time, is the best way to internalize how stages, processes, and steps fit together — reading about it only gets you so far.

Key takeaways

• The case life cycle hierarchy is Stage → Process → Step; a process is implemented as a flow rule.
• Primary stages form the happy path and auto-advance when their steps finish; alternate stages don’t, and require an explicit Change Stage automation to enter or exit.
• A stage can have a starting process (runs automatically, often the default pyStartCase flow) and optional processes (triggered on demand).
• Step types have distinct shapes: Collect information (green), Automation (yellow), Decision (orange diamond), Subprocess (blue) — learn to recognize them for the exam and for reading flows quickly.
• Design the primary path first; add alternate stages for exceptions afterward.

Next up: Module 3 — The Primary Path (Happy Path) and Alternate Stages, where we go deeper into designing exception handling. 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.