Case identification
The use of rules in Pega Platform™ follows the business process management best practice of recognizing the "separation of concerns" that exists between work and data. The Enterprise Class Structure (ECS) formalizes this distinction with its Work- and Data- classes. Pega uses Work-Cover-extending cases that one or more stages break down (in which are one or more Work-extending flows). The purpose of a flow is to manage business data, which the system implements by using a Data-extending class.
The role of a Lead System Architect (LSA) is to decide which Pega Platform features to use (such as cases, stages, steps, processes, subprocesses, data objects, child cases, related sibling cases, and components) when designing a solution.
In some business scenarios, you can identify a case type by whether it represents a single straightforward business process. However, in other situations, producing a robust design with longevity might 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 of the application.
The application design begins by finding the processes in the given business scenario, and then identifying a feature of Pega Platform to automate the process.
For example, In a Purchase Request process , a customer pick out items from a list and the quantity of each item to purchase are added to shopping cart. One or more approvers review the list, and once approved, the shopping cart items are ordered. When the original requestor ultimately receives the items, the process is complete.
You can use several case type designs to represent this business process:
- A single Purchase Request case type for the entire process, with sub-processes for each line item.
- A Purchase Request case type to gather the initial request that, when approved, spins off a single Purchase Order case type.
- A Purchase Request case type to gather the initial request with Purchase Order child case type for each line item.
All provided solutions might be initially viable, but the optimal solution considers current and potential future requirements to minimize maintenance.
Guidelines for identifying cases
Consider the following questions to consider when you identify cases:
- Does the case type represent the items that require processing, and does it involve multiple actors to complete the process?
- Is there a benefit to splitting the process into multiple case types or child case types, or are parallel processes (parallel flows) sufficient?
- If child case types exist, does the processing of the main case type depend on the completion of the child case types?
- Are there other current or future requirements, such as reporting and security, that are more easily implemented by adjusting the case type design?
- If every process has separate security requirements, then it makes sense to consider creating separate case type/ child case type
- If granular reporting is associated with the process, then it makes sense to consider creating separate case type/ child case type
- The infrastructure provided by case type processing for data (such as an approval process, security, or auditing) is advantageous, then providing a case type may be more suitable than updating the data directly.
Carefully consider all the questions. Some situations may not require additional cases and might result in inefficient resource use and overly complex solutions. Because creating case types involves additional processing, always ensure you have a good reason for creating additional case types.
The Purchase Request example illustrates the following points:
- If security requirements are based on individual line-item types of approval, you might need to implement the case type design solution with child case types for individual line items.
- If there is no specific requirement for line-item processing, a solution that involves sub-processes might suit each line item.
- Adding a Purchase Order case type might be unnecessary unless a requirement explicitly states the need for it (for example, special reporting requirements).
Check your knowledge with the following interaction:
This Topic is available in the following Module:
Want to help us improve this content?