Design approach

The application design process begins by identifying the processes in the given business scenario and then pinpointing a Pega Platform feature that can automate the Process.    

For example, in a Purchase Request Process, a customer selects items from a list and adds the quantity of each item to purchase to a shopping cart. One or more approvers review the list, and the order in the shopping cart goes through after approval. When the original requestor receives the items, the Process is complete.

You can represent this business process with several Case Type designs:   

• A single Purchase Request Case Type for the entire Process, with Subprocesses for each line item.   
• A Purchase Request Case Type to gather the initial request that, after approval, initiates a single Purchase Order Case Type.   
• A Purchase Request Case Type to gather the initial request with a Purchase Order child Case Type for each line item.   

All provided solutions could be viable initially, but the best solution considers current and potential future requirements to minimize maintenance.

Consider the following questions when you identify Cases:

Do the Case Types represent the items that need processing? Do they require multiple users to complete the Process?

• Is there a benefit to dividing the Process into multiple Case Types or child Case Types, or are parallel processes enough?
• If child Case Types exist, does the main Case Type processing depend on the completion of the child Case Types?
• Are there other current or future requirements, for example, reporting and security, that can be implemented more effectively by adjusting the Case Type design?
• If every Process has distinct security requirements, creating separate Case Types or child Case Types can be a viable option.
• If detailed reporting pertains to the Process, creating separate Case Types or child Case Types can be a viable option.
• If the infrastructure provided by Case Type processing for data, for example, an approval process, security, or auditing, is beneficial, providing a Case Type might be more suitable than directly updating the data.

Consider all the questions thoroughly. Some situations do not require additional Cases and might lead to inefficient resource use and overly complex solutions. Since creating Case Types involves more processing, ensure that there is a solid reason for creating additional Case Types.

The earlier Purchase Request example demonstrates the following points:

• If security requirements are based on individual line-item types of approval, then implementing the Case Type design solution with child Case Types for individual line items could be necessary.
• If there is no specific requirement for line-item processing, a solution that involves subprocesses could fit each line item.
• Adding a Purchase Order Case Type might not be necessary unless a requirement explicitly states the need for it, for example, special reporting requirements.

Check your knowledge with the following interaction: