Case identification

From the beginning, Pega has followed the business process management best practice of recognizing the Separation of Concerns that exists between work and data. Pega’s Enterprise Class Structure (ECS) formalizes this distinction with its Work- and Data- classes. Pega uses Work-Cover-extending cases that are broken down by one or more stages (within which are one or more Work-extending flows). The purpose of a flow is to manage business data, which is implemented using a Data-extending class.

The role of a Pega-certified lead system architect is to decide which Pega Platform™ features to use — cases, stages, steps, processes (flows), subprocesses (subflows), data objects, child cases (subcases), related sibling cases, components, and so on —when designing a solution. In some applications, a case type is easily identified as it represents a single straightforward business process. However, in other situations, producing a robust design with longevity may require careful consideration. Other dependencies on the design include reporting, security, locking, extensibility, and specialization. Carefully consider all present and potential future requirements before creating the design since this forms the foundation for the application.

The case design begins by identifying the processes in the application. As you identify case types, consider specialization needs for these case types. Also, carefully consider future extensibility requirements before implementing the case designs. For example, a Purchase Request process involves identifying a list of items and the quantity of each item to be purchased. The list of items is reviewed and then forwarded for approval by one or more approvers. Then, the list of items is ordered. When the original requestor ultimately receives the items, the process is complete.

You can use several case designs to represent this business process:

• A single Purchase Request Case for the entire process, with subprocesses for each line item.
• A Purchase Request case to gather the initial request that when approved spins off a single Purchase Order Case.
• A Purchase Request case to gather the initial request with Purchase Order child cases for each line item.

The decision on what to implement has a dependency on the Personas that will do the work. When some or every line item must be scrutinized, it makes sense to use the Divide-and-Conquer design pattern. Multiple persons working in parallel can process the list of LineItems faster than a single person having to look at each LineItem in succession.

All provided solutions may be initially viable, but the optimal solution considers current and possible future requirements to minimize maintenance.

Basic questions to consider when identifying cases include:

• Does the case represent the items that require processing?
• Is there a benefit to splitting the case (process) into multiple cases or child cases, or are parallel processes (parallel flows) sufficient?
• Is an additional case or child case required?
• If a child case is created, a general rule is that the processing of the main case depends on the completion of the child cases. Does this hold true?
• Are there other current or future requirements, such as reporting and security, that are more easily implemented by adjusting the case design?

Carefully consider all of the questions. Some situations may not require additional cases and might instead result in inefficient use of resources and an overly complex solution. Because creating cases involves additional processing, always ensure you have a good reason for creating additional cases.

The Purchase Request example illustrates the following points:

• If there are security requirements based on individual line item types' approval, you might need to implement the case design solution with child cases for individual line items.
• If there is no specific requirement for line item processing, the simple solution involving subprocesses might suit each line item..
• Adding a Purchase Order case may be unnecessary unless there was a requirement explicitly stating the need for it (for example, special reporting requirements)..

Case identification might be straightforward, or there might be situations where additional cases or processes are advantageous. For example, data might support the case processing, such as customer or account data. In situations where using the infrastructure provided by case processing for data (such as an approval process, security, or auditing) is advantageous, then providing a case may be more suitable than updating the data directly.