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  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 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 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 the step. This allows business analysts to describe the functionality for the step before application designers start their implementation.
• Configure the step as a single assignment, a process, or a case. Single-step assignments and cases are single-shape flows. The Process Outline treats these flows differently, by drilling down to the properties panel for the shape, rather than presenting the flow diagram.
• Control when users can perform the step, which allows you to configure parallel processing paths within a stage.
• Specify criteria to skip the step altogether, to perform steps only when they need to be performed.

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.

Federated Case Management

https://pdn.pega.com/sites/pdn.pega.com/files/help_v721/procomhelpmain.htm#concepts/casemanagement/con_federatedcasemanagement.htm%3FTocPath%3DPortals|Case%2520Manager%2520portal|Federated%2520Case%2520Management|_____0

 

Federated Case Management (FCM) uses the Pega Web Mashup connectivity to link Pega 7 Platform applications in a federation. FCM features integrate different Pega 7 Platform systems, allowing a user logged into an application to create, open, and work on cases in a different application from within his current application portal, without having to log in to another system or open another browser window. On each application in a federation, you select case types to make available to other applications as remote case types, so they can be viewed and accessed in other systems.
The FCM user interface allows users on their local system to:

• Use the New menu on the Case Manager or Case Worker portals to create and work on remote cases.

• Create and work on remote cases in their local system processes.
  Note: Users can only create top-level cases on the remote system.

• Open and work on cases that were instantiated on remote systems.

• Open and work in harnesses (such as My Cases on the Case Manager portal) located on remote systems.

In a federated system, the terms local and remote are relative to a specific user and to a specific case. Each user on a federated system logs into a single application, his or her local application. Remote cases (that is, cases in other applications within the federation) can be created, viewed, and worked on from within the user’s local application portal. No re-design of any application’s user interfaces is required. FCM enables users to create, view, and work on remote cases of that type from within the local application portal as though they were local cases, even though all processing for each case still occurs in its local application, and all of the data related to each case is still stored in its local application’s database. The diagram below illustrates an example in which a user logged into the CPM-FS application will be able to create, view, and work on DisputeTransaction cases in a separate application, SmartDispute.

In practice, the distinction between local and remote cases is irrelevant to the user. The FCMR consolidates work items and makes them available to all users in the federation. Users generally need not know the source of a case or assignment. All work performed on a case occurs in its local application, and all data for a case is stored in its local application’s database.
The FCMR contains class tables for federated versions of key classes, such as Work-Federated and Assign-Worklist-Federated. Instances of the federated classes serve as lightweight pointers to class instances residing in a federation’s local application databases.
To make publishing data to the FCMR as efficient as possible, federated classes in the repository contain no BLOB fields, only a handful of key properties such as ID and status needed to identify and open each case in its local application. The full data for a case resides in only one place, its local application database, and all processing for that case occurs within its local application, even when that processing is being done by a user within a remote application portal.
Consider the following FCM Limitations:

• Only top-level case types can be made available as remote cases.

• Some features, such as bulk processing and search, and standard reports do not operate on remote cases.

• As with local cases, users can only work on remote cases that are not locked by users on other systems.

Adding a remote case type and case type rule

Before you begin, perform the steps described in the PDN article Setting up and configuring Federated Case Management - Pega 7.1.
On each system, create a remote case type (an abstract class inheriting from Work-Cover-) and its case type rule. Each remote case type maps to one concrete case type in the remote application.
Do the following:

1. In the Case Type Explorer click the menu arrow and select Add a case type. The system displays the Case Type Explorer: Add dialog.

2. Expand the Advanced Settings area.

3. Select the Remote Case type check box.

4. Enter a case type name (do not start with a number; may include spaces) in the Name field. The value is used in the Class rule Description field; if there are spaces, the system concatenates the text in the Class Name key part.

5. Expand the Advanced Settings area.

6. In the Derives From (Directed)field, choose the class this case derives from for directed inheritance. By default, the class created for the new case type will inherit fromWork-Cover-.

7. In the Derives From (Pattern) field, choose the class this new item derives from for pattern inheritance. By default, the class created for the new case type will pattern inherit from the current work pool.

8. Select an application RuleSet and Version in the RuleSet and Version fields.

9. Click OK to close the dialog.

The remote case type and its case type rule appear in the Application Explorer. The case type also appears in the Case Designer Case Types tree; the only available actions are Open and Rename.
The Stages & Processes, Details, and Specifications tabs do not contain remote case type information; this resides on the remote system.
After you create the remote case type rule, configure the Remote Case Configuration tab. Click the case type definition link in one of the tabs.
Note: FCM systems can be chained; that is, a control system can also be employed as a remote system.
Caution: You must use the Remote Case type option to create remote case types and case type rules. You cannot create these rules using the Application Explorer or copying an existing rule. Be careful not to delete remote case type rules.

Related information

•  About Remote System data instances
• Case Type Explorer
• About case type rules
• Case Type form Completing the Remote Case Configuration tab
• Case Manager portal

Federated Case Management landing page

The Federated Case Management (FCM) landing page lets you publish data in bulk to the Federated Case Management Repository (FCMR), a centralized database that consolidates case data from all applications in a federation. The FCMR makes the consolidated cases and assignments available to the applications for processing by any authenticated user in the federation.
Bulk publishing is typically done when a new application is added to an existing federation, in order to load existing application data in the FCMR. Subsequently, case data is normally published to the FCMR in near-real-time as cases are created and changed within applications. Depending on the number of cases published, bulk publishing might require significant system resources and take a significant length of time. Only one application can publish to the FCMR at a time.
The FCMR contains class tables for federated versions of key classes, such as Work-Federated and Assign-Worklist-Federated. Instances of the federated classes serve as lightweight pointers to class instances residing in a federation’s local application databases.
Federated classes in the repository contain no BLOB fields, only a handful of key properties such as ID and status needed to identify and open each case in its local application. The full data for a case resides in only one place, its local application database, and all processing for that case occurs within its local application, even when that processing is being done by a user within a remote application portal.
Local applications update the FCMR whenever case and assignment data change. If the FCMR is unavailable for updates, the applications queue the changes to the FCMR agents: FCMRSave, FCMRSaveAssignWorkList, and FCMRSaveAssignWorkBasket. These agents update the FCMR when it is available to ensure that the application data and FCMR is always in sync.
Caution:
Disabling the FCMR queue agents might result in data loss.

Field	Description
Database	FCMR. You cannot edit this field. You can, however, open the FCMR database rule from here and edit connection and authentication information. See Database form - Completing the Database tab.
Data Type	Select one of the following: Work - Publishes all unresolved work/cases from the application selected in the Application field. Select Include resolved items. Optionally, enter dates to filter the resolved work that is bulk published to a date range. Administrative - Publishes all administrative data (operators, access groups, etc.) from your system. Assignments - Publishes all assignment data from the application.
Application	The field only applies when publishing work/cases. Select the application from which data should be published.
Include resolved items	This optional field only applies when publishing work/cases. By default, only unresolved items are published to the FCMR. You can use this option to publish resolved work/cases and choose to restrict your Resolved work to a date range.
Publish	Click to publish the work, administrative, or assignments data to the FCMR.
Abort	This button appears after clicking Publish. To cancel publishing, click Abort and confirm.
Show Bulk Processing History	Click to display the most recent publishing activity. Click a column header to sort by Application, Initiating User, Records Saved, Total Records, Current Step, or Status. Clicking a sortable column header displays a filter icon on some columns. Click the icon to filter the display by one or more entries in the column. Optionally select the check box for each item you want included in the display and click Apply. Optionally enter letters or numerals in the filtering field to narrow the list to items beginning with those characters. Click Apply. Click Clear Filter to display all items. Click Hide Bulk Processing History to remove the history display. This removes any filtering settings.
Last Run on	The date and status of the most recent publish operation based on the options selected.

 

 

Adding a child case type to your application

Add a child case type to your application to extend your case type hierarchy and modularize the way that you model work in your organization.
You can either reuse an existing case type or add a new case type to define a parent-child relationship. Add a new case type when no existing case types meet your business requirements.
Before you add a case type to your application, review your existing case types and case-type dependencies. Although reusing a case type saves time and effort, it can introduce unexpected complexity when a top-level case type is demoted.

·         Adding an existing child case type to your application

·         Adding a new child case type to your application

Related information

• Managing case types in your application
• Reviewing the existing case types in your application
• Examples of case-type dependency management
• Enabling automatic case instantiation

Adding a new child case type to your application

You can add a new child case type to your application to extend the case type hierarchy. By using child case types, you can define relationships and dependencies among case types in your application.

1.      In the explorer panel of Designer Studio, click Cases to open the Case Type Explorer.

2.      Hover over a parent case type name and click .

3.      Select Add a child case type.

4.      Click New case type.

5.      Click Next and enter a name for the child case type in the Create new field.

6.      Optional: Expand the Advanced Settings section to configure the rule resolution for the case type.

Options include:

7.      Click Finish.

The case type is added to your application but it does not have a life cycle or data model defined. You can define these now or at a later time.

Related information

• Adding a child case type to your application
• Defining a life cycle for a case type