Fundamentals of Case Design

Stakeholders typically describe their work through goals, responsibilities, decisions, exceptions, and outcomes rather than through Case Types, Stages, Processes, Steps, and Workflow. The Solution Designer interprets that business narrative, identifies the design signals it contains, and evaluates whether the proposed Case Design represents those signals clearly.

As Elena describes the booking operation, consider what her account reveals about the business outcome being delivered, how the work progresses, which milestones matter to stakeholders, and how the work is organized. These observations provide the evidence needed to evaluate the Tour Booking Case Design

U+ Travel Cala Verde: Elena describes the booking operation

The information revealed in Elena's account can be evaluated through four connected review questions. Together, they provide a structured way to review the proposed Case Design.

The four fundamental Case Design decisions

The four questions follow the same path as the Case itself, moving from the business outcome being delivered, through progression and visibility, to the work organized within each Stage:

• What business outcome is this Case Type responsible for delivering?
• How should the Case progress from initiation to each recognized resolution?
• Which points in that progression matter enough to be visible as Primary or Alternate Stages, and what Case Status information do stakeholders need?
• What related work belongs within each Stage, and how should it be organized into Processes and Steps?

The remainder of the topic applies these questions to Elena's account, examining one Case Design decision at a time. To begin, review the purpose served by each Pega Case Design construct.

The four Case Design decisions are represented through a small set of connected Pega constructs. These constructs work together to define the business outcome being managed, show how work progresses toward that outcome, provide visibility into current status, and organize the work required to complete it.

A Case Type defines the repeatable business transaction being managed. A Case is a specific instance of that transaction.

The following figure shows how the Tour Booking Case Type relates to individual customer Cases:

For U+ Travel, Tour Booking is the Case Type. Each customer booking is an individual Case that follows the Tour Booking Case Design while maintaining its own information, progress, and outcome.

These Cases progress through the same connected Case Design constructs.

The following figure shows the core Case Design constructs that work together within the Tour Booking Case Type:

Together, these constructs define the business outcome being managed, show how work progresses toward that outcome, provide visibility into the current state, and organize the work required to complete it.

The Solution Designer evaluates how these constructs work together to represent the business clearly and give stakeholders the visibility they need to understand and manage the transaction.

The following sections examine each of the four Case Design decisions in more detail, beginning with the business outcome represented by the Case Type.

Identify the right Case Type

The first Case Design decision is whether the proposed Case Type represents the correct business outcome. Stakeholders often describe activities, responsibilities, and events that occur during the work. The Solution Designer evaluates those details to determine the business transaction the organization is responsible for managing and the outcome it is intended to deliver.

Returning to Elena's account, consider the scope of U+ Travel's responsibility. The work begins when a customer wants to arrange a tour, yet Elena's team remains responsible for availability checks, confirmation, payment, preparation, safety requirements, customer communication, and completion of the tour itself.

A Case Type should represent the complete business transaction being managed, not simply the event that caused the work to begin. That distinction becomes clear when separating the trigger, transaction, and outcome.

Ask:

• What starts the work?
• What repeatable business transaction does the organization manage?
• What meaningful result is delivered when the Case resolves?

The following figure shows how the trigger, Tour Booking transaction, and intended outcome relate to one another:

The visitor’s request triggers the work, while Tour Booking represents the complete business transaction U+ Travel manages from request through completion.

This distinction helps explain why three different Case Type names might emerge from Elena's account:

Stakeholders often describe a transaction through the activities they perform. Each activity may be important, yet importance alone does not make it a separate Case Type. Availability Check, Collect Payment, Prepare Equipment, Monitor Weather, and Confirm Consent all contribute to managing the same Tour Booking transaction. Keeping this work connected provides one journey to manage, one progression to monitor, and one business result to measure.

When evaluating a proposed Case Type, consider:

• Does it represent a repeatable business transaction with a recognizable outcome?
• Does it provide the scope needed to manage that transaction from initiation to resolution?
• Does the name describe the transaction rather than an activity, team, channel, or starting event?
• Would stakeholders recognize the value delivered when a Case completes?

Creating specialized Case Types

Start with one baseline Case Type. Create a specialized Case Type when the variation materially changes the structure or governance of the work.

Create a specialized Case Type when any of these are materially different:

• Process lifecycle: The Stages, Steps, end-to-end journey, or core work sequence is substantially different.
• Data requirements: Different core Data Objects or significantly different data elements must be captured and used.
• Service-Level Agreement (SLA) and compliance: The work has distinct mandated timelines, audit requirements, controls, or regulatory obligations.

Do not create a specialized Case Type just because of:

• Different products
• Jurisdiction-specific rules
• Different routing or teams
• Reporting requirements

These variations can typically be handled through configuration, rules, routing, and reporting within the same Case Type.

A clearly defined business outcome provides the foundation for designing the Case Life Cycle. The next decision is how progress toward that outcome becomes visible

A well-designed Case Life Cycle helps stakeholders understand where a Case stands, what has been achieved, what remains, and how the transaction can conclude.

Evaluating the Case Life Cycle requires four connected decisions: establish the primary path, identify the meaningful Primary Stages, represent recognized alternate and resolution paths, and define the Case Status information stakeholders need.

Establish the primary path

A Case Life Cycle becomes meaningful when stakeholders can recognize how work progresses toward the intended outcome. Start by identifying the path most Cases are expected to follow. This primary path provides a shared view of how work normally progresses before considering variations, exceptions, and alternate outcomes.

Applied to Elena's account, the primary path emerges from how she describes usual processing. Most bookings progress from the initial customer request through confirmation and preparation to the completed tour. This provides the first view of the Tour Booking primary path:

The following figure shows the primary path most Tour Booking Cases are expected to follow:

Test the primary path against the complete work journey

The primary path should represent the complete journey the business follows to achieve its intended outcome. Before refining Stages, Status, or Workflow behavior, confirm that the major responsibilities required to move work from an initial request to a completed result are visible somewhere in that journey.

One useful review technique is the 6Rs: Receive, Route, Research, Review, Respond, and Resolve. Together they represent the broad responsibilities that commonly occur as organizations receive work, progress it, make decisions, communicate with stakeholders, and reach a business outcome. The 6Rs help the Solution Designer identify gaps, missing transitions, and responsibilities that may not yet be visible in the design.

Use the following table to review how each responsibility appears in the Tour Booking  Case Type. At this stage, focus on whether each responsibility is represented clearly in the design. The following sections examine how those responsibilities are made visible through the Case Life Cycle, Workflow, and organization of work.

The following figure shows the six responsibilities used to review whether the primary path represents the complete work journey:

The six responsibilities can be represented flexibly across the Case Life Cycle. One Stage may support several responsibilities, and a responsibility may recur as the Case progresses. Use the 6Rs to confirm that the primary path represents the responsibilities required to deliver the intended outcome, and to identify areas where progression, transitions, or visibility can be represented more clearly.

The primary path does more than show the order of the work. It gives stakeholders a shared view of how most Tour Booking Cases are expected to progress, where a Case currently stands, and what remains before the intended outcome is achieved.

Design Primary Stages as meaningful milestones

A Primary Stage represents a meaningful business milestone in the Case Life Cycle. Together, the Primary Stages make progress visible and establish the primary path stakeholders use to understand how work advances toward the intended outcome. Identify the points in that journey that matter enough to be made visible as Primary Stages.

Applied to Elena's account, the milestones emerge from what the operations team needs to see. Elena needs to know which bookings have been requested, which are confirmed, which tours are prepared, and which have been completed.

These states allow the operations team to recognize what has been achieved, understand where each booking stands, and focus attention on the work still required.

Elena may describe the same journey through the activities or teams involved: the booking team reviews the request, payment is arranged, and operations prepares the tour. These details remain important for Process design and routing. The Primary Stages should communicate the resulting business progress.

The teams and activities have not disappeared from the design. They will be represented through Processes, Steps, ownership, and routing. The Stage names provide a stable business view of progress that remains meaningful even if the teams or routing arrangements change.

Evaluate whether a milestone should be a Primary Stage

A point in the primary path should be represented as a Primary Stage when it communicates progress that stakeholders need to understand:

• Has the Case reached a meaningful new business state?
• Would stakeholders recognize what has been achieved?
• Does this point help users understand where the Case stands and what remains?
• Is the milestone useful for operational monitoring, communication, or reporting?
• Would the Stage remain meaningful if ownership or routing changed?

A handoff or ownership change can be a useful signal, but it does not automatically require a new Stage. The Stage must still represent meaningful business progress.

Together, Booking Requested, Booking Confirmed, Tour Prepared, and Tour Completed communicate the expected progression toward successful resolution. With the primary path and its milestones established, the next decision is which deviations and recognized endings require lifecycle visibility.

Design Alternate Stages and resolution paths

After establishing the primary path and its milestones, identify the business states and outcomes that stakeholders need to recognize separately. Some variations require focused work before the Case returns to the expected journey. Others lead to a different recognized outcome and conclusion.

Primary Stages communicate the expected progression toward the intended outcome. Alternate Stages communicate meaningful business states or outcomes that stakeholders need to recognize separately. When a variation creates a distinct business state or recognized outcome, it may warrant lifecycle visibility through an Alternate Stage. Variations that change how work is completed can remain within the current Process when the business progress being communicated remains unchanged.

Applied to Elena’s account, late consent may require a distinct business state while the booking waits to proceed. Once consent is received, the Case can return to the primary path. Severe weather or a customer cancelation may instead lead to a recognized outcome that resolves the Case. The following animation shows how these alternate paths relate to the Tour Booking primary path.

Evaluate lifecycle visibility

Use the following questions to determine whether a variation warrants lifecycle visibility:

• Does the variation create a meaningful Case state that stakeholders need to recognize?
• Should the Case return to the primary path or conclude through another recognized outcome?
• Would the distinction support communication, monitoring, or reporting?

Connect Stages, resolution, and Case Status

Stages show the major milestones in the Case Life Cycle. Case Status provides a concise business description of the current state or final disposition. Used together, they create a shared language for customers, business users, operations teams, and leaders.

A Status should communicate information that helps stakeholders understand the current business situation or outcome. While Pega classifies work broadly as New, Open, Pending, or Resolved, the Status design should reflect the distinctions users need to make while work is progressing and after it has concluded. Where automation or Agent-driven work influences progression, Status information can provide additional visibility into the current state of the business transaction. Use the Status values the business needs for informed action, operational monitoring, and reporting, while keeping the vocabulary consistent and easy to interpret.

Applied to Elena's account, the Status design follows directly from the information her team needs to act on and report.  During peak season Elena needs to distinguish bookings that are confirmed, those still needing attention, and those fully prepared. After the tour, she needs to know whether the booking completed or was canceled.

Evaluate the Status design

To evaluate the Status design, consider the following questions:

• Does the Status add meaning beyond the Stage name?
• Can users identify where attention or action is required?
• Does the resolved Status communicate how the Case concluded?
• Can the Status vocabulary be applied consistently across comparable Case Types?

With the Case Life Cycle, recognized outcomes, and Status information established, the next decision is what related work belongs within each Stage and how that work should be organized.

A Stage contains one or more Processes that organize the significant areas of work required to reach the milestone. Each Process contains the specific user-driven, system-driven, or Agent-driven actions represented as Steps.

Returning to Elena’s account, Tour Prepared communicates that the operational requirements for the tour are in place. Reaching this milestone requires work such as preparing specialist equipment, arranging transport, and completing safety checks. The Solution Designer organizes these related areas of work into Processes and defines the Steps required to complete each Process.

Organize related work into Processes and Steps

A Process groups the Steps that collectively accomplish a clear purpose within the Stage. The Process makes a significant area of work visible, while its Steps describe the specific actions required to complete it.

Applied to Elena's account, equipment preparation groups several related actions. Elena explains that it includes confirming that the required gear is available, checking the safety equipment, and loading the vehicle.

These actions contribute to one coherent purpose and can therefore be organized within a Prepare Equipment Process.

The Process communicates what the related work accomplishes. The Steps identify the specific user-driven, system-driven, or Agent-driven actions required to complete it.

A Step always belongs within a Process. When interpreting stakeholder input, first identify the significant area of work and the purpose it serves. Then identify the individual actions required to complete that work.

Name Processes and Steps clearly

Name Processes and Steps using a verb and noun. The Process name should communicate what the related Steps collectively accomplish, while each Step name should describe a specific user-driven, system-driven, or Agent-driven action.

In the Prepare Equipment Process:

• Prepare describes the overall action performed by the Process.
• Equipment identifies what the Process acts upon.
• Confirm Gear Availability, Check Safety Equipment, and Load Vehicle describe the specific actions that contribute to completing the Process.

Use names that communicate business meaning without requiring additional interpretation. Avoid vague labels such as Equipment, Equipment Work, or Handle Equipment, which do not clearly explain what the Process or Step accomplishes.

Describe Processes and Steps clearly

A clear Process or Step name communicates the action and its business purpose, while the Step type shows how the action is performed. Use the description to preserve the additional business intent and Authoring detail that are not already represented through the Step type or other Blueprint configuration.

For a user-driven Step, describe what the participant must accomplish and any important information or presentation intent. For a system-driven Step, describe what the system should do and the expected business result. Where more specialized Step types require conditions, outcomes, dependencies, or authorization, capture that intent through the relevant Blueprint configuration and description.

Select and describe an Agent-driven Step

Use an Agent-driven Step when the Process requires interpretation, analysis, classification, extraction, synthesis, or drafting across the data, information, knowledge, and context available to the Case. The Step should contribute a clear business result, such as reducing operational effort, improving consistency, accelerating progression, or helping work continue at greater scale.

Begin with the business need and the result the Process requires. Identify what the business needs to accomplish at this point in the Process, what enables the Case to progress, and whether an AI Agent could create meaningful value by performing that action.

For the selected Agent-driven Step, describe the business action, the data, information, knowledge, and Case context available to the AI Agent, the requi    ed result, and where that result is captured in the Case. Confirm that the Step has the information it needs to act, contributes a clear business result, and provides what the next Step or Workflow path requires for continued progression.

This gives stakeholders enough information to validate the purpose and placement of the Step and provides the Solution Builder with a clear basis for Authoring.

At this point in the design, focus on the business purpose and required result. The Workflow design determines how Agent-driven work is coordinated with participant review, exception handling, and continued progression.

Add only the detail needed for stakeholders to validate the work and for the Solution Builder to carry its intent into Authoring.

Evaluate how the work is organized

When reviewing the Processes and Steps within a Stage, consider:

• Does each Process represent a significant and coherent area of work?
• Does each Process have a clear purpose that contributes to achieving the Stage milestone?
• Do the Steps within the Process collectively deliver that purpose?
• Does each Step describe one specific user-driven, system-driven, or Agent-driven action?
• Are significant areas of work visible as Processes rather than compressed into individual Steps?
• Are Process and Step names clear and meaningful to business stakeholders?

Review the Tour Booking Case Design as one connected representation of the business outcome, its progression, meaningful milestones, current state, and organization of work.

Use the 6Rs as one lens within the design review. Confirm that the Case accounts for how work is received, routed, researched, reviewed, responded to, and resolved, and that the Stages still communicate the progress stakeholders need to understand. Where a Step may be Agent-driven, confirm that its business purpose and required result are clear enough to support the Workflow behavior that follows.

End-of-topic design test

A stakeholder can recognize the business outcome, follow the Case through each meaningful milestone and recognized resolution, understand its current Status, and explain how the work is organized within each Stage.

With the Case structure established, Topic 2 examines how work progresses, adapts, and reaches the appropriate outcome through Process flow, parallel Processes, Automation Steps, Business Rules, Decisions, conditional execution, optional behavior, and Workflow destinations.

Check your knowledge with the following interaction.