How to create and design a Case Type in Pega (PRPC) Platform Application

8 min readMar 2, 2023

Case Types are used in a Pega Platform Application to define the life cycle of a type of work aka case. A case life cycle or workflow acts as a road map for completing a certain type of work. A work could be any business transaction — from opening a savings bank account to buying a automobile insurance, from ordering grocery online to filing income tax return. Case life cycle consists of the different stages or milestones through which a case moves during its processing before it is resolved. Not only the stages, a case life cycle also includes the different processes and actions — manual or automated. A case type in Pega helps to design the case life cycle in an easy-to-understand pictorial manner by using different building blocks for stages, processes and actions constituting the life cycle. It can also reflect what participants are interacting with the case at a certain point in its life cycle.

Let’s go through the method to create and design a case type in its bare bones form in Pega. For explanation purpose, I’m going to use the example of online food order system that allows a customer to place an order for food; a restaurant would then accept the order, and a delivery partner would deliver it to the customer.

Part A — Create a new Case Type

Step# 1 — Launch Add Case Type Modal Dialog

Select the Case types in the left navigation panel. It would launch the Case Types Explorer with a link to Add a case type as shown below. Click on the link.

It would open the Add case type modal dialog as shown below.

Step# 2— Choose Case Type Name, Parent class(s) and Ruleset

Enter a meaningful name for your case type. I’ve used Online Order in my case.

Thereafter, expand the Advanced Settings node in the modal dialog to specify parent class and ruleset of your case type.

Insight — When you create a new Case Type, the system auto-generates a Work class for the case type, that derives from a parent class(s).

There are two types of inheritance in Pega — Directed and Pattern. You need to identify the parent class(s) of your case type class through both the inheritance types in two different fields as shown below. The Directed parent class can be same as well as different from the Pattern parent as per your requirement. If they’re different, then your case type class would derive or inherit from two different classes. In my case, I’ve chosen the same class, i.e. the Work class in my implementation layer (MyOrg-MyDiv-Beta-Work) as the Directed as well as the Pattern parent as shown below.

Add case type dialog — Advanced Settings

Insight — The name of the case type class is derived from that of its parent class (Pattern) and the case type name.

In line with the above principle, MyOrg-MyDiv-Beta-Work-OnlineOrder would become the name of the case type class in my case.

In addition to the Work class, the system auto-generates a few other rules. Select an appropriate ruleset and its version to place the auto-generated rules. In my case, I’ve chosen the implementation layer ruleset (Beta) as shown above.

Finally, click on the Submit button in the above dialog. It would create the new case type, open it in Case Designer as shown below.

Part B — Design the Case Type

Next, you need to design your case type or case life cycle in the Case Designer. Follow the below method to design it.

Method —

First break down your business transaction into different stages.
Thereafter, further break down each stage into different processes, and each process into multiple steps.

A Stage signifies a milestone in a case life cycle. A change of stage typically represents a change in the case participant, or a significant change in the case status.
Process is a sequence of steps combined together.
A Step represents an action — either user performed or automated.

Stages, processes and steps, when put together in Case Designer, constitute the case life cycle in Pega.

Insight — While designing the case life cycle or workflow you’re essentially grouping different actionable items (steps) into a process, combining together different processes to be performed by a participant into a stage, and finally putting together different stages to form the case life cycle.

Tip — Initially, look at your business transaction in a wholistic way to identify the different stages involved. Afterward, shift your focus on each stage to determine the different processes or steps involved therein.

Using the above method, I’ve broken down the online-food-order case into the following stages, processes and steps —

Let’s add them in the Case Designer to form the case life cycle.

Step# 1 — Add Stages in the Case Designer

You would notice that after the case type is created, the system by default adds one stage named Create, and one process, also named Create to the case life cycle. I have renamed the stage and the process therein to align with the requirement as shown below.

I’ve added the remaining stages by +STAGE button as shown below.

Step# 2— Add Processes and Steps

As shown below, I’ve identified the following steps within the first stage, and have added them by clicking on +FORM STEP button.

In order to add a step to the second stage, hover over the corresponding PROCESS. As you hover, a +STEP button, as shown below, would appear.

Click on it, and select Collect Information.

Then provide a relevant name to your step.

As apparent from above, when you add the first step to a stage, the system automatically creates a process with the same name, and includes the step within it. You are not required to create a process separately. You can rename the process if required as shown below.

Similarly, I’ve added the steps to the remaining stages as shown below

Step# 3— Optionally add Alternate Stages

You can optionally add alternate stage(s) to your case type by +ALTERNATE STAGE button.

The stages, namely — Order Placement, Restaurant Acceptance, Food Preparation and Delivery, added above, define the happy path for Online Food Order case, and are known as Primary stages. Whereas, Alternate stages are used to define the path for a case to traverse in unusual or exceptional circumstances, for example — a customer cancelling his/her order, or a restaurant declining an order, etc.

As shown below, I’ve added three alternate stages, viz. — Cancellation, Cancellation Acceptance, and Refund to the case type to handle for the unusual event of order cancellation by customer. Similarly, you can identify the exceptional circumstances in your case, and add them as alternate stages (along with processes and steps) in your case type.

This completes the bare bones or fundamental design of the case type. Of course, there are a host of other details that can be configured or built into the case type, such as — routing, status update, decisioning, service level agreement, automation, optional processes, and many more. But they’re all a subject of future discussion.

Auto-Generated rules

The system auto-generates a number of rules as you create a new Case Type. In order to learn about the auto-generated rules, go to the App Explorer in the left panel, and search with the Work class of the case type. In my case, as explained above, MyOrg-MyDiv-Beta-Work-OnlineOrder is the case type class.

Afterward, explore the different rule categories under it, such as Data Model, Process, SysAdmin, etc., as shown below.

Lastly, let’s look at some of the auto-generated rules.

1) Class rule for the Case Type

In the App Explorer, navigate to SysAdmin -> Class as shown below.

Click on the class name to open the class rule form as shown below.

2) Case Type Rule

The system auto-generates a case type rule named pyDefault. A lot of details such as child case type, local actions, primary stages, alternate stages, optional processes, locking, temporary case, etc. can be configured in the case type rule.

Navigate to Process -> Case Type in the App Explorer as shown below.