Creating case stages
Creating case stages
| Creating case stages | |
|---|---|
| New URL | https://docs.pega.com/bundle/platform-88/page/platform/case-management/best-practices-creating-using-stages.html |
| This article has been moved over to our Pega Community here in order to align with our larger content strategy. Please update any bookmarks or links that you may have to this location. | |
Case stages are an essential part of defining a case type. For more information, see Stages in a case life cycle.
Primary stages
Primary stages represent the “happy path” that the majority of cases will follow towards a successful outcome. The following best practices help identify the primary stages of a case:
- Should the majority of cases of this type go through this stage?
- Would completing the steps in this stage be considered part of usual case processing?
- Do the processes in this stage represent a key component of the case life cycle?
- Is going through this stage required for a positive resolution of the case?
For non-resolution stages, Pega recommends giving stages such names that make the following types of sentences sound correct:
- This case is in <stage name>.
- How many cases are in <stage name>?
- When will this case move to <stage name>?
For more information, see Creating a primary stage.
Example
An application has a case type that manages the process of an employee requesting to travel. It has 4 stages: Request, Review, Booking, Confirmed. The first stage collects information about where the employee is traveling. The second stage manages the approval of the request. The third stage books the travel. The final stage describes the outcome, which in this case, is that the travel is confirmed. The transition from the Request to Review stage happens when sufficient data has been collected from the employee to send the request to a manager for review. The transition from Review to Booking is based on an approval, or human decision by the manager, to allow the case to continue. The transition from Booking to Confirmed happens automatically after the travel agent has completed the reservations. Pega recommends defining between four and seven primary stages in a case type. The stages should be sequenced through a logical progression.
Alternate stages
Pega recommends that you use alternate stages to define exception handling scenarios and negative resolutions. Alternate stages are optional and most commonly represent a negative resolution stage that diverts the case from the happy path, such as Withdrawn or Rejected. Alternate stages used for exception handling allow the case to reenter the primary path at the correct point when the exception is handled.
Use the following best practices to help identify the alternate stages within a case:
- Does this represent a negative resolution?
- Is this an exception or error scenario that the minority of cases will go through?
For more information, see Creating an alternate stage.
Example
The travel request case might have three alternate stages: Withdrawn, Rejected, and Booking exception. Withdrawn and Rejected represent negative resolutions. The originator might withdraw the request, or their manager might reject the request respectively. You can use a Booking exception stage to handle automated booking failures that require additional manual intervention to complete.
Resolution stages
Resolution stages indicate that the case will finish its life cycle upon conclusion of the stage. Every case type should have at least one resolution stage, and frequently there are several resolution stages in any microjourney. There are almost always alternate resolution stages – such as Withdrawal and Rejection. One resolution stage is always the last primary stage, and the alternate stages might include several resolution stages. Pega recommends giving resolution stages names that include a noun, such as Completion, Rejection, Withdrawal, Fulfillment, or Resolution. Pega recommends defining corresponding resolution statuses for each resolution stage such as Resolved-Completed, Resolved-Rejected, etc.
Stage transitions
Moving from one stage to the next indicates a transition involving the case. Pega recommends that you base stage transitions on one of the following conditions:
- All automated processing required to complete a stage has been completed.
- A human decision or approval is made to allow the case to continue.
You can use several ways to transition from one stage to another, both through Automations and Assignments. When you click on a stage, the following three options are available in the details panel:
- Automatically move to next stage
- Wait for a user action
- Resolve the case
After all actions in the stage have been completed, this setting determines how to transition out of this stage.
Use the following best practices to help identify which stage transition to use.
- Automatically move to next stage if all of the data required to enter the next stage has been captured or a business event will automatically advance the case (i.e. waiting for a child case to complete).
- Wait for a user action if an approval or series of approvals is required for the case to continue. This is a manual transition based on a human decision.
- Resolve the case if the case life cycle reaches an outcome when the stage completes.
For more information, see Moving a case to a different stage.
Related information
Creating a Microjourney for customer success
Adding case types to organize work
The Microjourney in the Pega Express methodology - frequently asked questions