Case Design

Case Design

CASE MANAGEMENT - UNDER THE HOOD

Click on Case Type open Case Designer 

Tabs of Case Designer

• Stages & Processes
• Under each stage, we can click on “Configure Process Detail” link to open the Process view of the Case Designer, or simply the Process View. 
• "Back to Stages” button to get back to the stages & processes tab
• Details tab to configure the case
• top most parent case only has Email Instantiation configuration
• any case that has subcases has the Data Propagation configuration item
• All subcases also have Instantiation configuration
• The Case Designer Specifications tab is used to document the business requirements related to the case.

 Case Type rule

• Processes tab stores the configuration information we saw on the detail tab of the case designer:
• work parties, 
• data propagation
• case wide supporting processes
• case wide local action 
• case match which is for duplicate search
•  list of subcases that are part of this case
• starting processes - is the first process that runs when users click on “create” from the Create menu in the portal. The starting flow usually consists of only one utility shape ( “pzInitializeStage”) if the case utilizes stages.we can have multiple starting processes. For each starting process, there is an entry in the “Create” menu for the end users.
•  The Stages tab of this rule stores the stages & processes tab information of the case designer. We can see the primary stages, configuration of each stage and configuration of each step as shown below. This tab also stores the information related to alternate stages, very similar to primary stages information
• The Calculation tab stores the calculations that are configured in the details tab of the Case Designer.
• We can use the Attachment Categories tab in the Case Type rule to add new categories associated with the case on which we are working. This tab does not store any information from the Case Designer.
• The Advanced tab does not store any information from the case designer as well. We can use the “Advanced” tab to publish as a remote case type, which is required for “Federated Case Management.”  The locking configuration in the Case Designer and the locking configuration here in the advanced tab of the case type rule are different. Case Designer locking configuration is valid for cases that are instantiated under a case hierarchy. The locking configuration here is valid for cases that are instantiated as stand-alone case instances.

Now, we can add flows from the current layer and flow from any class in the whole direct inheritance tree.
We can open the flow rule associated with each step from the “Open” menu item of the Step Options menu.

CASE LIFECYCLE MANAGEMENT

The stages of a case identify different phases a case instance goes through. A stage identifies where a case instance is, at a specific time.

Stages comprise a set of actions that can either be a single step, multiple steps or launch another case.

We configure the stage behavior with the “Configure Stage Behavior” menu option.

Stage configuration dialog box:

• Stage Name
• Stage service level agreement – Applies a service level rule to the stage. The service level starts when the case enters the stage, and ends when the case leaves the stage or the process otherwise stops.
• Skip stage when — Use this option to skip a stage if a when rule resolves to true
• Is this a resolution stage? — By checking the box we identify the current stage as a resolution stage. A resolution stage indicates a stage where you expect to resolve a case. When selected the stage name is underlined in red, in the Case Explorer. When a stage is marked as a resolution stage, a case is not automatically resolved upon completion of that stage. 
• When all stage processes are completed or skipped —
  • Transition to the next stage - when all the steps are processed, the case instance transitions automatically to the next stage in the primary stages.
  • Stay in the current stage -  tools such as the Change Stage smart shape or the Change Stage flow action allows the system or the end user to move to another stage.
• OPTIONAL PROCESSES — We can specify optional processes, which are implemented as flow rules. These optional processes appear to end users in the Perform Harness, under the “Other actions” menu. Users can run optional processes as needed. 
• OPTIONAL ACTIONS — We can have optional actions, which are implemented as local flow actions. These optional actions appear to end users in the perform harness, under the “Other actions” menu.   Local action when processed does not make the case instance to move from the assignment shape.

Specific to	Configured on	Available to End Users
Assignment	Assignment Shape	Only in that specific assignment
Flow wide	Flow rule	In all the assignments of a specific step
Stage wide	Stage Configuration as shown above	In all the assignments of a specific stage
Case Wide	Case Designer – Details Tab	In any assignment throughout the case

We can also use a validate rule to determine whether the case enters the stage or not, by selecting Configure entry validation from the menu. This provides us with two validation options:

• Stage entry validation – a specified validate rule runs against the case.
• Attachment validation – the case must contain an attachment of the specified type.

If either validation fails, the case returns to the previous stage with the appropriate validation error message.

Configure Steps

Remember that each step creates a flow rule.

We can configure the step behavior with the menu option “Configure step behaviors.”

Step configuration dialog box:

• Step Description — Enter a description or a specification. Specification and specification actions are covered under a different lesson.
  
  
• Step Type — As a step type, we can choose one of the following:
  • Single Step Assignment  — creates a flow rule with a single assignment shape.
  • Case —  it creates a flow rule with a single “Create Case(s)” smart shape.
  • Approval — creates a flow rule with a single subprocess shape. The subprocess shape calls the standard pzApprovalFlowWrapper flow. Approval steps can be configured for processing by a single operator, or a cascading series of operators based upon either the existing reporting structure or an authority matrix configured by a decision table. The cascading approval option behaves similarly to the Cascading Approval smart shape, and can be configured in the same manner.
  • Attachment — creates a flow rule with a single subprocess shape. The subprocess shape calls the standard pzAttachFile flow, which itself consists of a single assignment that calls the pxAttachContent flow action.
  • Multi Step Process — creates a flow rule with two assignment shapes.  The flow rule can be edited to add more shapes or to remove shapes. In essence, any flow that does not qualify as an Assignment, Case, Approval or Attachment stage is a multi-step process step.
• Start Step 
• Upon stage entry – steps are processed concurrently when the case instance enters this specific stage. 
• Upon completion or skip of previous step – steps are processed sequentially when the case instance enters this specific stage.
The first step of a stage must always have “upon stage entry” set to true. For any subsequent steps, we can choose either concurrent or sequential evaluation. Each step configured to start upon stage entry begins a new step sequence, and each sequence is indicated with a double line colored blue.
• … and when — We can have a when rule in this field. If the when rule is false, the step is skippe.
• When a specific step of a stage is processed, subsequent step in that stage will be automatically kicked off, if that is marked to start “upon completion or skip or previous step.” In the previous step, if we change to a previous stage using the “Change Stage” smart shape, another step in the previous stage also started. If this effect of two steps across two stages getting kicked off is not desired, we can have the standard when rule “pxIsInCurrentStage” in the subsequent step.
• Launch on re-entry? — Once a stage is processed it can be re-entered from another stage by the change stage process or manually by the end user. Only the steps that have this option selected are started automatically when the stage is re-entered. 

Runtime User Interface of the Stages

When a case that is designed with stages is instantiated, we can see what stage the case instance is in. All the primary stages show in blue and the stage we are in appears in black. Alternate stages appear between the primary stages where the case instance deviates from the happy path.

Using the summary view of any standard portal, end users can quickly get an idea of how many cases are in each stage of the case lifecycle. The number next to the stage names indicates the number of instances in that stage.

Clicking the number pulls a standard report as shown below.

In the portal, from the drop down, end users can change to different cases to pull the summary for that case.

CASE HIERARCHY

Use the Advanced Setting to Create Subcases

When creating a parent case, subcases or any stand-alone case, we can change the default settings of inheritance, and the ruleset version.

To add a case, from the Case Explorer select Manage Case Type > Add a case type.

Create Case Type” dialog box (advanced settings)

Derives From (Directed) — We use this field to change the directed inheritance chain. All the cases are typically derived from Work-Cover- or one of its descendants, so that we want can take advantage of several standard features available in Work-Cover- abstract class and its super classes.

Derives from (Pattern) — We use this field to change the pattern inheritance chain. Choose the appropriate class from the dropdown maximizes reuse and let’s indicate where we want the rule resolution algorithm to pull the rules from. We can choose the same workpool class as that of the parent, the class of the parent case, the class of a sibling case or a class of any case in the application on which we are working.

Ruleset and Version - Use this field select the ruleset and version where the Case Type rule for the case is going to be saved. 

Remote Case Type — Use this field to select the Remote Case type to publish this case as a remote case for another application. This is only required for Federated Case Management. Federated Case Management will be covered under a different lesson in an advanced course.

Create Starting Process — Use this field to create the pyStartCase flow rule, with a default short description of Create case name. Always select this option when creating cases because this creates a starting flow “pyStartCase” which has one utility shape “pzInitializeStage” that initializes the stages. This starting flow rule can be edited later to change the short description for the create menu and/or to change the flow rule, if necessary.

If we need to change any of these settings after the creation of the subcase, just update the Class Group and Parent class fields in the class definition form.

If we need to change the ruleset or ruleset version, save the pyDefault Case Type rule under the appropriate ruleset and/or version. Then we can add more starting flows in the Process tab of the pyDefault Case Type rule. We can also select or deselect “Publish as Remote case type” in the advanced tab of the same Case Type rule.

Instantiate Subcases In the Case Hierarchy

• Subcase Case Designer
• Step Configuration  in the Parent Case Designer
• Create Case Smart Shape in any Flow rule

Using the Subcase Case Designer we can instantiate a subcase automatically or manually. To instantiate a subcase instance automatically and/or manually by our end users, select Case Designer> Details Table and click the Edit link by Instantiation.

We  can also instantiate , by selecting the check box “Automatically by system when” and select the radio button “the parent case starts.” Or we can use a When rule and when it evaluates to true, the subcase gets instantiated.

Instead of instantiating the subcase automatically when the parent case starts, we can instantiate the subcases based on dependencies. The dependency is called an instantiation dependency. We can configure the subcase to instantiate when “any or all” dependencies are met.

If the dependency is the parent case for a subcase to be instantiated, the dependency condition can only be “Has work status.” A specific work status can be selected from the drop down box next to “Has Work status.”

If the dependency is another sibling subcase, a subcase can be instantiated automatically when the sibling subcase has started, has a specific work status or has completed.

We can select “Manually by user when” we want to use a When rule and then when the rule evaluates to true, our users can create a subcase manually.

Using the Step Configuration in the Parent Case Designer

We can use this configuration option whenever we want a subcase is to be instantiated automatically by the system when a step of a stage is reached in the parent case,. This method gives us more options of instantiating multiple case instances or a top level case.

In the case designer of the parent case, we can add a step in an appropriate stage and we can configure it to instantiate a subcase instance. We can also use an optional When rule and the subcase instance is instantiated only when that rule evaluates to true.

we can select create a top case, create a subcase or create multiple subcases as instantiation options

If we choose the “Create a top case” option instead the case is to instantiated as a top level case, that is, it is not a subcase of a parent case. Any case can be instantiated as stand-alone top level case. We can also create another parent case, if the situation warrants.

If we select the “Create multiple subcases” option multiple subcases are instantiated from a page list.

We can view the instantiation of subcases in a step by reviewing the case designer of the parent case.

Using the Create Case Smart Shape in any Flow rule

We can use this configuration option whenever a subcase is to be instantiated from a flow rule of any case regardless of parent or sibling or the case itself. This method gives us more options when instantiating multiple case instances or a top level case.

A subcase can be instantiated in any flow rule by adding the Create Case(s) smart shape. To add the Create Cases smart shape to the flow rule, select the Shapes menu > Smart Shapes. Once the shape is added to the flow rule, the shape can be configured just like a step in the Case step type configuration.

Getting Data from the Parent Case to the Subcase(s)

In the Case Designer of the parent case, we can use the Data Propagation option to set the values in the subcase(s). The Data Propagation option can be found on the Details tab of the Case Designer. To propagate data from the parent case to the subcase, we click the edit link next to Data Propagation, to open “Case Designer: Data Propagation” dialog box.

We can propagate the data from the parent case Purchase Request into the subcases, Purchase Order and Inventory Selection. If we are simply taking the data without making any changes, we can use the data propagation option. We do not have to select “Also apply Data Transform.” If we are using the data conditionally or looping through a page list or if we need to reuse propagating data from parent to the subcase, we can use the “Also apply Data Transform,” option as well.

Using a data transform rule, we can propagate data from parent case to the subcase in the step configuration, in the case designer of the parent case.

Aggregate Data from Subcases to the Parent Case

If we want to track the total cost of something, we would need to aggregate the calculation in the parent case from the properties of all the subcases that have been instantiated within the parent case.

In the Case Designer of the parent case, we can use the Calculations option to set the values in the subcase(s). The Calculations option can be found on the Details tab of the Case Designer.

Calculation configuration information is stored in the Processes tab of the Case Type rule of the parent case.

Once the calculation is configured in the parent case, the system creates declare triggers in the appropriate subcases. Here, we can see pyCaseTypeAggregate declare trigger rule for both subcases. When we modify the property of a subcase, it triggers a standard activity to do the calculations.

Use Locking Configurations Default locking locks the case when an operator opens the case. If a second operator tries to open the same case, they get a message that the case is locked by the first operator. The second operator is able to open the case in review mode only. The lock is acquired when the case was opened by the first operator. No actions can be taken. Optimistic locking enables both the operators to open the case. No lock is obtained when the case is opened. The lock occurs when the user clicks Submit. When two operators are working on the same case, the changes to the case are made by whoever submits the case first. The second operator receives a message with the first operator’s name and the time of the change. Also there is a refresh button that allows the second operator to get the new changes made by the first operator. The second operator’s changes are not applied until they click refresh and submit their action after the refresh. In the Case Designer of the parent case, we can use the Locking option to set locking on the top most parent case. If the subcases are instantiated as part of the parent case, they have the same locking settings as the parent. The Locking option can be found on the Details tab of the Case Designer. The Default locking timeout is 30 minutes but can easily be changed to a custom timeout as shown below. we can change the custom timeout for the subcase, irrespective of the timeout settings in the parent case, for default locking configuration. We can also set parent case locking in the subcase locking configuration. The default option is to lock the parent case when the subcase is being worked on. We can change this but the recommended approach for most use cases is to lock the parent when the subcase is being worked on. If the “Do not lock” option is selected, the parent case is not locked when the subcase is being worked on. The advantage of using the “Do not lock” option, both the parent and subcases can be processed simultaneously. The main disadvantage of using the “Do not lock’” option  is that  since the parent case is not locked, any properties related to the subcases, such as count of open subcases is not updated in the parent case. If this is not important and simultaneous processing is preferred, then select the “Do not lock” check box. Any time we change to optimistic locking or change the lock timeout in default locking, we are using custom lock settings.  These locking settings are persisted on the Case Type record in the following properties, pyLockingMode, and pyLockTimeout. If the locking mode is default locking without a custom timeout specified, then the lock timeout is obtained by the Data-SystemAdmin setting pxCoveredInskeys – This property holds the handles or pzInskeys of the subcases that are linked to the parent case. If needed, we can reference this value list property in our application. This might be useful if there is a need to list or identify all the subcases instances of a specific parent case. pxCoveredCount – This property indicates the number of subcases linked to the parent. Anytime, a subcase is added or removed from the parent, the system automatically updates the value of this property. PRPC uses this property to indicate whether a parent case contains subcase instances and behaves accordingly. pxCoveredCountOpen – A standard property that holds the number of subcase instances within a parent that are not resolved yet. As the subcases are being resolved, PRPC keeps this count updated automatically. This property value is used to ensure that there are no open subcases within the parent case.  CREATING AND EDITING FLOWS ADVANCED FLOW PROCESSING SCREEN FLOWS WORK STATUS Every case instance must have a status, which changes as the case instance progresses through stages and flows associated with the steps. PRPC provides several standard work status values. We can also create our own statuses.There are four broad categories of work status values: New  (a green Flag) A “New” work status indicates that the case instance has just been created and has not been reviewed or qualified for processing. Open(a blue Flag) The “Open” status indicates that the case instance is being processed by the organization which is supposed to process it. Pending(a red Flag) The “Pending” status indicates that the responsibility of processing the case instance is currently with an external organization. So the processing of the case instance is suspended until the external organization or group has done its part. Resolved (a checkered Flag - finish) A “Resolved” status is generally the final status for a case instance as it indicates the completion of the work. Usually, a case instance in a “resolved” status is not modified by any later processing. Resolved items are stored in the database and no longer appear on a work list or in a workbasket. Users can work on a resolved work item; but first it must be reopened. A few standard values are defined in each category. To access them, click Designer Studio > Process & Rules > Processes > Status Values.  We can also define more status values through Field Value rules(pyWorkStatus). When doing so, we need to make sure that we start each value with one of the words New, Open, Pending and Resolved (using the initial capital). From any of the explorers, create a new rule instance under Data Model > Field Value. Use PRPC Standards to Update Work Status Most flow shapes, including Start, Assignment, End and Smart shapes, provide a means to set or update work status. To set or update the property Work-.pyStatusWork value, do not use the “property-set” activity method or use a data transform rule to set a value for this property, but instead, use the Properties panel of the flow shapes. The “Status” tab on the panel allows us to define the new work status value by providing a value in the “Work Status” field. This is the preferred way. As a best practice, the status for an assignment shape should never be set to “Resolved” because the work item’s status is updated when the assignment is reached. If the status is resolved, the user is unable to perform any additional work on it. When the work status is set on a shape, we will see the status flag indicator on the connector leading to that shape in the flow rule. The flow “End” shape provides two fields: “Flow Result” and “Work Status.” Make sure to use “Work Status” for this purpose.  If the flow belongs to the last step of the “resolution” stage, work status is one of the “Resolved” status field values, such as “Resolved-Completed,” “Resolved-Withdrawn,” “Resolved-Canceled” etc. When we set the work status of a case, PRPC uses the standard activity Work-.UpdateStatus to update the value of the property Work-.pyStatusWork. An activity is a sequence of structured steps, designed to automate some aspect of case processing. The activity Work-.UpdateStatus, which can also be called from a flow utility shape, changes the property directly and calls some standard activities such as Work-.Resolve if the status value is one that started with the word “Resolved”. There are also a few standard rules which call the Work-.UpdateStatus activity. Activities such as Work-.WorkBasket and Work-.Worklist which place an assignment in a workbasket or worklist respectively, also call Work-UpdateStatus. Key standard functionalities which leverage the Work Status When a case instance/work item status is first updated to a “Resolved” status, PRPC calls the Resolve activity automatically. This activity activates the “Status-Resolved” ticket.  Another particular standard ticket is “AllCoveredResolved.” If a subcase status becomes Resolved, the immediate parent case is checked. These standard tickets are covered in the “Tickets” lesson.  PRPC also automatically maintains three standard properties in Work-class. They are pyElapsedStatusNew, pyElapsedStatusOpen and pyElapsedStatusPending. These properties contain cumulative time in seconds that a case instance has had a status value that started with the word “New”, “Open” or “Pending” respectively. WORK PARTIES A work party represents an entity that needs to be notified about the progress or status of work. When a case is created as part of a new application through the Application Express wizard or added to an existing application through the case addition menu in the case explorer, the system creates a default Work Parties rule for the newly created case. This rule can easily be configured from the Details tab of the Case Designer. edit link displays the “Parties”  By default, PRPC adds three roles, Customer, Owner, and Interested with the appropriate default properties values in the Work Parties rule instance for the case on which we are working. Each row defined represents a person or an entity that can participate or be interested in the case instance progress. Each row concisely describes a role and their part in the process. A role can be standard roles such as Owner, Customer etc., or we can create more specific roles such as LoanOfficer. The Description is the unique name for each of the roles we see displayed in the user interface. The Party Type field references the data class that contains the properties we’ll use to store the work party information. We will see the details of the Party Type later in this lesson. The Model field is optional and is a data transform rule that defines the initial properties of our work party when adding the work party to a case instance.. It causes the system to set initial values for some properties of the work party. We will learn more about this later in this lesson. The “Display on Creation” checkbox can be selected to if we want the work party to appear at runtime when the case instance/work item entry form first appears. The “Required” field indicates that this party must be present in every new case instance/work item. The “Allow Multiple” check box, when selected, allows for the addition of multiple instances of a single work party role. Simply specify the role you want to repeat in the field. This, for example, is useful if we want to add dependents to an auto or life insurance policy. When we open the case type rule, we notice that it references a work parties rule named “pyCaseManagementDefault”. Work Party Data Structure The Party Type on the configuration form of the Case Designer, can be one of the following: Party/Company, Party/Government, Party/Operator, Party/Non-profit, Party/Person or it can be any other custom party that you create. Party Types are defined in PRPC as instances of the Data-Party class or one of its sub-classes. Process Commander organizes the Data-Party data into meaningful categories. Data-Party-Com for business organizations, and the Party/Company Party Type roles are instances of this class. Data-Party-Gov for Government organizations, and the Party/Government Party Type roles are instances of this class. Data-Party-Operator for PRPC application users with an Operator ID record, and the Party/Operator Party Type roles are instances of this class. Data-Party-Org is reserved for the non-profit organizations, and the Party/Non-profit Party Type roles are instances of this class. Data-Party-Person is designed for any person who is not however a PRPC application user, and the Party/Person Party Type roles are instances of this class. We can create our own sub-classes (either direct or pattern inherited from Data-Party) if we need to expand more categories of work parties for our application, like Employee, Manager or Dependent as shown below. The drop down for the model shows the data transform rules. The data transform rules defined in the class related “Party Type” field or in one of its parent class show up as entries in the Model drop down A substantial set of Work party properties are delivered with PRPC. A few properties are required, such as: pxPartyRole, which identifies the role of the party. pyWorkPartyUri, which uniquely identifies the party. pyEmail1, which Pega 7 uses to send notifications to the party. If we don’t provide a value for pyWorkPartyUri, Pega 7 uses pyEmail1 to determine a value when validating the work party using the standard activity Data-Party-.Validate.  Some commonly used – though not required – properties include pyLastName, pyFullName, and pyAddress. Add a Work Party to a Case Instance In the parties configuration of the Case Designer, if we marked a Party Role as “Display on Creation,” (or “Required,” which automatically marks “Display on Creation”) the work party is created when the case instance is created. We can see the Work Parties information in the standard perform harnesses on the right hand side at runtime of the case instance creation. We can click the “Edit” button to add more work parties or update existing work parties to the case instance at runtime. Flow has reference to work parties rule The Work Parties rule listed in the case type rule takes precedence if a different rule is referenced in flow. If we uncheck the “Skip create harness”, then when the case instance is instantiated, the new harness displays first, before the actual case is instantiated. In New harness - We can edit existing work party or add new work parties in this new harness as well, such as the perform harness. If the perform harness is customized or some other harness is used and if we don’t have the capability to add a work party at runtime, we can either include the “Work- • pyWorkPartiesWrapper” section rule wherever we want or we can use the “AddParty” flow action as local action at the assignment level,the flow level, the stage level or the case level. Below is the configuration at the assignment level local action. At runtime, from other actions menu, we can click on the “Add a party” link and this brings the same section to edit existing parties or to add new parties just as we saw before in the new harness and the perform harness. Once the work parties are added to a case instance, we can send correspondence or route an assignment to the parties. Correspondence and routing are covered in other lessons in this course.