Case identification

A case type represents a group of functionality that facilitates both the design time configuration and run-time processing of cases. Pega Platform provides many features that support case processing, such as the case life cycle design (including stages and steps), reporting, and security.

The LSA decides which Pega Platform features to use—processes (flows) , subprocesses (subflows), data objects, child cases (subcases), or other components—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.

In the Pega Platform, other dependencies on the design include reporting, security, locking, extensibility, and specialization. Consider all requirements before creating the design since this forms the foundation for the application.

The case design begins by identifying the processes in the application. Next, you determine if child cases are warranted, including any additional processes that may benefit from case management. 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 the items, and 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 items are ultimately received by the original requestor, 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

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

Basic questions to consider when identifying cases include:

• Does the case represent the item(s) 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 really 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 case(s). Does this hold true?
• Are there other present or future requirements, such as reporting and security, that may be more easily implemented by adjusting the case design?

Carefully consider all of the questions. Some situations may not require additional cases(s) and could instead result in an 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 previous Purchase Request example above illustrates these points:

• If there were security requirements based on the approval of individual line item types, 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 for each line item might be suitable.
• Adding a Purchase Order case may be unnecessary unless there was a requirement specifically stating the need for it (for example, special reporting requirements).

Case identification may be straightforward or there may be situations where additional cases or processes could be advantageous. An example of this is data that may 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—may be advantageous, then providing a case may be more suitable than updating the data directly.