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.
