Effective case management requires that individual contributors complete steps in a coordinated manner so that they can resolve the case efficiently.
These steps – which may represent whole processes and subcases – are analogous to entries on a checklist, representing objectives to be completed to resolve the case. Without any context, however, the relationships and dependencies between these objectives are invisible to both application designers and the persons resolving the case. By organizing these elements into stages, you provide both application designers and end-users with an understanding of the entire lifecycle of the case.
If an Accounting department wanted to create a case management application to coordinate the purchase, procurement, and fulfillment of goods and services, an application designer might divide the workflow into a series of case stages that represent groupings of related tasks, such as:
- The employee (requestor) files their request.
- A vendor is added to the request.
- A price for each good or service is quoted.
- The purchase request is routed through the appropriate approval chain.
- The goods and services requested are procured and provided to the requestor.
- The purchase request is closed.
Within each stage, you group the steps – tasks, processes, and subcases – to be performed, providing a clearer view of the lifecycle of the case to developers and end-users.
In our example, subcases for purchase orders – one for each vendor quoted on the purchase request – are clearly part of one stage. Case lifecycle management allows an application designer to easily delay the creation of any purchase order until the purchase request reaches the appropriate stage, and manages the stages of each purchase order subcase independently of its parent purchase request.
With case lifecycle management, you can:
- Easily transition between groups of tasks, without the need for complex switching logic.
- Establish precedence and dependency relationships between processing tasks.
- Provide a big-picture view of all of the tasks, processes, and policies that make up a case.
These and other benefits of case lifecycle management allow Pega 7 to provide a more natural, business-friendly way to develop an application.
As part of the process of creating a new application, Application Express creates one or more case types according to the information you provide.
Each case type consists of a series of stages, which allow application designers to collect tasks in a loose chronological order. Cases consist of primary stages and alternate stages. A primary stage represents a portion of the preferred, optimal path for resolving the case, while an alternate stage represents a deviation from the preferred path, such as a set of steps that are not performed at a consistent point in the lifecycle of the case.
Within each stage, you can add and delete steps. A step is the fundamental processing action – comparable to an item on a checklist – that must be performed to resolve the case, such as:
- Collect items for order.
- Calculate delivery charge.
- Approve request.
A step can represent either an individual task, a subprocess, or a subcase that must be completed to resolve the case. Each step represents a flow rule; this allows you to reuse a step as needed by simply referencing the existing flow rule on a new step.
To add a new step to a stage:
- Position the cursor over the stage.
- Click the Add step placeholder that appears.
- Enter the name of the step. If the name corresponds to an existing flow rule, the step uses the existing flow. Otherwise, PRPC creates a flow rule with the name you specify.
To delete a step, click the and select Delete this step. Deleting a step only removes the step from the stage, and does not delete the flow rule referenced by the step.
To provide visibility into the logic of a step, the Process Outline allows an application designer to drill down into the process represented by each step. To open the Process Outline, click Configure process detail, visible at the bottom of each stage.
To bypass the Process Outline and view the flow rule directly, click the Open.
menu and select
This section describes the options presented in the Step Configuration dialog. To update the flow rule represented by the step, see the article Manage your flows with Process Outline
Each step represents an action that must be performed to process and ultimately resolve a case, and can be configured to mirror a real-world workflow. The Step Configuration dialog allows you to control the behavior of each step, as part of the overall lifecycle of the case. To open this dialog for a particular step, hover over the step, open the Configure step behaviors.
menu when it appears, and select
With this dialog, you can:
The top portion of the Step Configuration contains a rich-text editor that you can use to document the intent of the step.
The information you provide is automatically saved as a specification rule, which can be reviewed on the Specifications tab of the Case Designer. When you reuse an existing flow, the specification associated with that flow appears in the dialog.
By default, each new step is a single-step process, containing one assignment. You can change a step to represent either a multi-step process or a subcase to create by selecting either Multi Step Process or Case from the Step Type drop-down list.
Steps can be configured to either run in sequence, or run simultaneously when the case enters that stage. By default, your application performs the steps in each stage sequentially, starting with the first (top) step of the stage. To allow for parallel processing of steps, you can designate a step to run when the case enters the stage that contains the step.
To allow an end user to perform the step when the case enters the stage, select upon stage entry. Steps that run upon entering the stage are indicated with a blue double line, denoting the various processing paths available in the stage. Within each path, steps are processed sequentially.
In the Stage Designer, parallel paths can only be established upon entry into the stage. If you need to establish a parallel path at a later step, you must use a Split-Join shape in the flow rule for that step.
Only steps that are performed upon stage entry and steps that create subcases can be used as a re-entry point for the stage. For more information on entry points, see the Developer Help topic entry point.
Each step can also be configured with a When rule to test whether the step should be skipped or not. For example, if you want to model a case to open a bank account and want to skip a step if the applicant is an existing customer, you could use a When rule to test if the applicant is already a customer. If the When rule returns a true result, your application skips the step when processing the case.