Thursday, July 13, 2017

Pega Case Managment

Configure Stages for Your Application
As part of the process of creating a new application, PRPC creates one or more case types, according to the information you provide in Application Express. Each of these case types contains three stages by default. You can add additional primary stages or alternate stages, delete existing stages, and reorder stages as needed to model the lifecycle of your case.

Each stage can be configured with steps and optional actions, which can range in scope from single tasks to complex, multi-step processes. PRPC manages automatic steps, starting them either in sequential order or simultaneously upon entering the stage. Optional actions are available during the appropriate stage, but are performed at the discretion of the end user.
Once all of the actions in a primary stage have been completed, the case can automatically transition to the next primary stage, while controlled transitions allow cases to move to any stage. Application designers can also block entry into a stage if initial criteria are not met, or skip a stage entirely under certain conditions.
Once all required stages have been completed, the case can be resolved. To indicate this point – and to prevent the case from transitioning automatically to another stage – you can designate a stage as a resolution stage. The resolution stage acts as a visual indicator of the end of the lifecycle of the case, but does not automatically resolve the case.

Adding, Removing and Reordering Stages

A stage represents the first level of case decomposition. Stages are high-level groupings, allowing application designers to organize the required and optional tasks that are performed as a case is processed and resolved. You can use stages to develop a sense of the tasks that must be performed in sequence, those that can occur in parallel, and optional tasks that can be performed at the discretion of the end user.
If you think of steps as the tasks necessary to process a case, stages are a means of sequencing those tasks and establishing dependency relationships between them.
By default, Application Express provides three stages when creating a case type. As a best practice, cases should not exceed nine (9) primary stages – a case that contains more stages may not have been fully decomposed, and may contain multiple cases or subcases.
As a general rule, cases should include at least three (3) stages. Remember, however, that stages are a tool to aid in managing a process. If two stages are sufficient to establish an understanding of the lifecycle of a case, an application designer should not feel compelled to create additional stages.
A subcase may often consist of fewer than three (3) stages, however, as it represents only a portion of the overall business process.

Add a primary stage

To create a primary stage, click the icon to the right of the last stage. This automatically adds a new stage to the end of the case lifecycle.

Add an alternate stage

Unlike primary stages, which are intended to be run for most – if not all – cases defined by a case type, alternate stages allow you to group exception actions or "ad hoc" steps. To add an alternate stage, click the Actions menu on the Case Type form and select Configure Alternate Stages. Alternate stages appear below the primary stages, and are indicated with a gold background, rather than a blue background.

When considering the use of an alternate stage, keep the following points in mind:
  • Alternate stages do not support automatic transitions. To exit an alternate stage, you must configure a controlled transition.
  • Alternate stages should not be used in place of a subcase.
  • An alternate stage may represent either an exception path, or a primary stage that does not occur at a defined point in the overall case lifecycle.

Delete a stage

To delete either a primary or an alternate stage, click the Stage Options menu icon icon_StepOptions.png and select Delete this stage. When you delete a primary stage, the Stage Designer automatically renumbers the following stages to ensure the success of any automatic stage transition.

Reorder primary stages

You can change the order of primary stages as needed to model the lifecycle of your case. Click Edit Stages to open the Edit Primary Stages dialog, which allows you to drag and drop stages to reorder them. With this dialog, you can also add new stages and delete existing ones.

When you click OK, the Stage Designer refreshes to reflect your changes.

Configure a Stage

For each stage, you can use the Stage Configuration dialog to configure stage transition options, set the stage to be a resolution stage, and add optional, stage-level processes and actions. To open the Stage Configuration dialog, click the Stage Options menu icon and select Configure stage behaviors.

Automatic and Optional Actions

Within each stage, steps represent processing actions that must be taken to complete the stage and ultimately resolve the case. Steps are performed in a prescribed order, managed by PRPC. Optional actions can be left to the end user's discretion.
To create and configure steps, see the article Design Your Application with Case Lifecycle Management.

Automatic steps

By default, the steps added to a stage are processed automatically, in sequential order.

Steps can also be configured to run immediately when the case enters that stage.
To distinguish between steps that occur in sequence and those that occur upon entering the stage, a blue double line divides parallel processing paths within the stage. Within each path, all actions occur in sequential order. When processing a case, the end user can perform an available step in any processing path.

In the previous example, Send Email, and Enter Accounting Information are actions available to the end user when their case enters the Procurement stage. If the end user then completes the Enter Accounting Information step, the next actions would be Send Email and Create Orders.
By default, the end user is prompted to perform the first (topmost) available step when the case enters the stage, although all current steps are available on the Overview tab of the case, if the end user has been granted the necessary security privileges.

In the previous example, the Get Program Approval assignment is pending for one user, while the Get IT Approval assignment is pending for another user. Either user can log in and process their assignment, without disrupting the case flow for the other user.
To skip a step, you can configure a When rule as a condition for performing the action. When the case reaches the action, PRPC evaluates the When rule. If the result is true, PRPC skips the action and advances to the next action in the sequence.

Optional actions

Optional actions – either processes or flow actions – can be added to the stage configuration, and do not appear as steps within the Stage Designer. To perform an optional action, select the desired action from the Other Actions menu.
An optional action configured for a stage can be run from any assignment within that stage, if the end user has the necessary security permissions. To restrict the availability of an optional action, configure a When rule to test whether the action should be available to the end user. Optional actions restricted in this manner are available to the end user only when the When rule returns a true result.

Transitioning to Another Stage

In order to continue processing, a case must transition to the next stage once a stage is complete. For primary stages, the default option is an automatic transition to the next primary stage. To direct a case to a different primary stage, or an alternate stage, you must specify a controlled transition. Controlled transitions can be configured for any primary or alternate stage, and can occur either at a specific point in a process, or​ as an optional action​. You can also prevent a transition if certain qualifications are not​ met, and skip a primary stage altogether under specific circumstances​.

Automatic transitions at stage end

By default, all primary stages automatically transition to the following stage once all of the steps in that stage are either completed or skipped. This ensures that the case is always available for processing. In the Stage Designer, stages with automatic transitions appear with an angled right edge.

To disable the automatic transition for a primary stage, open the Stage Configuration dialog and select Occurs manually by end user or as defined in a process model.

Controlled transitions

In situations where you want to allow transitions to alternate stages, or prior to the completion of the stage, you can add a controlled transition to a stage. Controlled transitions can be either added to a specific point in a process by use of the Change Stage smart shape, or left to the end-user by use of the Change Stage flow action as an optional action.
When PRPC encounters a Change Stage smart shape in a process, it automatically transitions the case to the specified stage. The Change Stage shape is most useful for automating transitions to and from alternate stages.
The Change Stage flow action allows the user to select the stage to which the case transitions. You can add the Change Stage flow action to an individual assignment as a local action, to a connector, or to the entire stage as an optional action.

Skip a stage

In certain situations, you may need to skip a primary stage entirely and proceed to the following stage. To avoid entering a stage, you can create a testable condition with a When rule, referenced from the Stage Configuration dialog.
If the When rule returns a true (positive) result, your application skips the stage – and all of its actions – and proceeds to the next primary stage. You cannot skip an alternate stage, as your application cannot identify the next stage to enter.
To configure a case to skip a specific stage:
  1. Create a When rule to test a specific condition and return a true or false answer. Remember that in the event of a true result, PRPC skips the stage.
  2. Click the Options menu on the stage, and select Configure stage behaviors.
  3. In the Stage Configuration menu, select your When rule in the Skip stage when field.
  4. Click OK and save the case.
Whenever your application attempts to transition to a new primary stage, it evaluates any skip condition configured for the stage. If the when rule returns a false result, the case enters the stage. If the When rule returns a true result, PRPC skips the stage and proceeds to the next primary stage.
If your application cannot transition the case into a new stage, processing of the case halts at the current step. If this happens, an end user must manually perform a transition to a stage that the case can enter.

Validate a case prior to stage entry

In certain situations, you may need to confirm that a case has been sufficiently processed before entering a stage. To ensure that a case only enters a stage when it meets certain qualifying criteria, you can use a validation rule to test the case.
Cases that fail validation do not enter a new stage. Instead, the end user receives an error message indicating the failure, and the case remains in the current stage.
Once a case fails stage-entry validation, a new transition attempt must be made to advance the case, as PRPC does not re-attempt the transition. When using stage-entry validation on either an automatic transition or a transition performed by the Change Stage smart shape, add the Change Stage flow action to the stage being exited as an optional action, as this allows the user to attempt the transition once the validation conditions are satisfied.

Resolving a Case

Once you have decomposed the lifecycle of a case into stages, the last stage should be identified as a resolution stage. Resolution stages are indicated in the Stage Designer with a vertical right edge, rather than an angled edge, and a red line across the bottom.

Completing a resolution stage does not automatically resolve the case. Cases in the resolution stage must be resolved by changing the status of the case to a "Resolved-" status, such as Resolved-Completed or Resolved-Withdrawn.
Unlike other stages, resolution stages do not allow an automatic transition upon completion, although controlled transitions – either using the Change Stage smart shape or the Change Stage flow action – can be configured.
A case may contain any number of primary or alternate resolution stages.

Contextual property panel in Case Designer

The contextual property panel in Case Designer helps you to quickly configure behavior in your case type. It supports: case-wide properties, stage properties, and properties that are specific to an individual step.
By default, the property panel displays case-wide properties when you open a case type in Case Designer.
Contextual property panel in Case Designer
Case-wide properties are categorized based on the behavior that you can control. Click a category name to access more options. For example, click Case-wide local actions to configure the flow actions that users can run when a case is in any stage or step.
Configuring local actions in the property panel
When you click a stage or step in your case type, the property panel automatically displays the relevant fields and controls. For each stage, you can add processes and local actions, set the validation logic that is evaluated before a stage is entered, and you can configure other properties, such as the transition method or service-level agreement.
 Available options in the property panel when a stage is in focus
For each step in a stage, you can configure the step type, access Form Builder, and open the underlying flow. Click the step type to update its details. For example, you can change your step type to Case and configure your step to create child cases based on a page list that is provided.
Available options in the property panel when a step is in focus
Help is integrated with the property panel to give you just-in-time information. Click ? to view a contextual help topic. Click More information to open the help system, which includes all topics, the search gadget, and a glossary.
The Details tab and drop-down menus for stages and steps in Case Designer are no longer supported. They have been migrated to relevant options in the contextual property panel.

Design Your Application with Case Lifecycle Management

ffective 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.

Design a case lifecycle

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:
  1. Position the cursor over the stage.
  2. Click the Add step placeholder that appears.
  3. 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 Step Options menu icon_StepOptions.pngand 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 Step Options menu and select Open.

Configure case steps

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 Step Options menu when it appears, and select Configure step behaviors.

With this dialog, you can:

Add a specification to describe a step

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.

Adjust the step type

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.

Start steps sequentially or simultaneously

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.

Perform steps conditionally

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.