In many case management applications, subcases are created and automatically begin their processes when a parent case starts.

However, there may be business situations where a subcase, before it can begin its process, depends upon another case type instance to start, complete, or reach a specified work status. Using the Case Designer, you can configure a case type so that it automatically instantiates when another case type instance satisfies one or more of these conditions.

Suggested Approach

You are working with an equipment request case management application, which is structured as shown below. The top-level Equipment Request case type is the parent of Inventory and Shipment.

When an Equipment Request case is created, an Inventory subcase is also created. If the items are in the warehouse, the case worker creates an In Stock subcase. When the inventory items are physically retrieved from inventory, the case worker manually creates a Shipment subcase.

Business requirement

It has been decided that the Shipment subcase will be automatically created when an In Stock subcase reaches the inventory retrieval task.

Configuration requirements

You will create an instantiation dependency for the Shipment case type as follows:

• Create a work status value named Retrieved-Verified and add it to the appropriate Assignment shape in the In Stock process.
• Define the dependency condition for the Shipment subcase type.
• Define the conditional instantiation method at the top-level Equipment Request.

Configure

Do the following:

1. Create a field value in the of EquipmentOrder-Work Applies To class using a Field Name of .pyStatusWork, and a Field Value of Retrieved-Verified.
2. Open the Case Designer (> Process & Rules > Case Management > Case Designer).
3. On the case types tree, select In Stock to open the In Stock case type's starter flow.
4. Select the Items Retried assignment shape, and open its Assignment Properties panel.
5. Open the Status tab and select Retrieved-Verified in the Work Status field.
   
6. Save the rule.
7. In the Case Designer, select Shipment in the case types tree.
8. On the Details tab, select the Dependencies (Edit) link.
   
9. In the Define Dependencies pop-up dialog, select the following values:
   • Depends on — In Stock.
   • Dependency — Any Case
   • Satisfied When — Has Reached Status. In the field that appears, select the work status Retrieved-Verified
     

10. Click OK to close the dialog.
11. Select Equipment Request on the case types tree.
12. On the Details tab, select the Instantiation (Edit) link to open the Instantiation dialog.
13. For the Shipment covered work type, select the Automatic instantiation checkbox and the Upon Dependency Fulfillment radio button.
    
14. Click OK to close the dialog.

Test

1. Create an Equipment Request case
2. In the action area header, select Other Actions >Add Work > Start Inventory to create an Inventory case.
   
3. On the Inventory perform harness select In Stock to create an In Stock case.
   
   The In Stock case has a status of Pending.
   
4. Select the Equipment Request link in the form header to open the case's review harness.
   
   Note: The Shipment case has not been instantiated.
5. Select the In Stock assignment to open its perform harness.
6. Select Submit to advance the flow to the Items Received assignment. The work status is now Retrieved-Verified.
   
7. Select the Equipment Request link. Because the In Stock case has reached the dependent work status, the Shipment case is automatically instantiated.

Altering case type dependency relationships

Case type dependency relationships are stored in the top-level case type rule. Be careful when changing the case type hierarchy, which can alter dependency relationships.

Example One

If you promote a subcase type to a top-level so that it is not coverable by any other case type, all of its dependency relationships are deleted.

Assume subcase type Package depends upon its peer Inspect to instantiate. If you make Inspect a top-level case type, the relationship defined in Package is removed. The row in its Define Dependencies dialog and the dependency data in top-level case type Equipment Request is deleted.

Example Two

If you add a top-level case type to a subcase type under another top-level, the dependency data for all of the subcase types are copied to the new top level. The data in the original top-level is deleted.

For example, assume you add a top-level case type named Order Fulfillment. To it, you add Equipment Request as a subcase type; its existing hierarchy moves with it , and the dependency relationships remain in tact. The dependency data for all its subcase types is copied to Order Fulfillment. The Equipment Request data is deleted.