Process and Rules category — Case Designer

Option

Description

• Add a subcase type to this case type by creating a new one, or by reusing an existing one.
• Add supporting processes to this case type.

When you select this option, the Add dialog appears.

Adding a subcase

Do the following:

1. Select the Case radio button.
2. Create or reuse a subcase as follows:

• Create a new subcase type for this case type — In the Name field, enter a case type name. May contain spaces between characters. The name appears in the Case Designer tree and in the Description label on the Case Type rule form. The name is concatenated and used as the Class Name key part. See Class Rules — Completing the New or Save As form.
• Reuse an existing subcase type not already covered by this case type — Select the Use Existing checkbox. In the Name field, select a case type in your application. Any existing subcase relationships remain in tact. If you select a top-level case type, it is demoted to a subcase and may significantly alter dependency relationships (defined in the Dependencies item on the Details tab).

3. Advanced Settings — Optional. Appears only when adding a new case type. Click () to expand the area. The following fields appear:

• Derives From. Choose the class this new item derives from by clicking () or create this class by clicking (). By default, new case types inherit from Work-Cover-.
• RuleSet. Select the new item's RuleSet.
• Version. Select the RuleSet version.
• Create Starting Process. Clear this checkbox if you do not want to automatically create a default starter flow for this case type. Selected by default.

4. Click OK to close the dialog. Either of the following occurs:

– If you are reusing an existing case type, the system updates the Coverable Work Types list on the parent's Case Type rule form's Processes tab, and saves the rule.

– If you are creating a subcase type, the system updates the parent's Coverable Work Type's list, and creates a new case type class and a set of standard rules (described below) within the current work pool.

About standard rules used in case types

When you add a new case type, the system creates the following standard rules:

• Class — Created in the work pool you are extending; inherits from Work-Cover-. The Class Name key part is the name you entered in the Add dialog. Spaces are removed.
• pyDefault case type — For subcase types, adds this case type on the parent's Case Type rule form's Coverable Work Types list.
• OpenDefaults activity — For future use.
• Start<class name> starter flow — The new Flow Name key part is a concatenation of the word "Start" with the Class Name key part. The name that appears on the tree is the value you entered in the Name field on the Add dialog. This name also populates the Flow Rule form's Description label.
• pyCaseManagementDefault work parties — Copied from the Work-Cover-.pyCaseManagement instance. By default, this value populates the Work Parties field on the starter rule form's Process tab.

Adding a supporting process to a case type

This option enables you to add processes that can run concurrently with the main process. From the Add a Case or Process dialog do the following:

1. Select the Process radio button.
2. In Process field, select a flow that can be added to an open case created by a previous flow execution.
3. Click OK to close the dialog, add the flow to the Supporting Processes list on the Case Type rule's form's Processes tab, and save the rule.
4. The Supporting Processes item on the Details tab is also updated. Select the item to configure how and when this process will start (manually or automatically).

Adding a top-level case type

1. Click the + Add Case Type link in the Case Types heading to open the Create Case Type dialog.
2. Leave the Use Existing checkbox blank.
3. Enter a case type name in the Name field.
4. Leave the Parent field blank.
5. Click OK.

You can also use the + Add Case Type link to add subcases. Follow the instructions described above.

About Federated Case Management

Federated Case Management (FCM) uses Internet Application Composer (IAC) connectivity to establish case management relationships between a PRPC system (control) where users create and work on cases in an application hosted on another V6.3+ system (remote). The FCM user interface allows users on the control 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 control system processes.
  
  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.

Adding a remote case type and case type rule

Before you begin, do the following:

1. On the control system, install the Gateway Configuration Console web application, which supports the deployment of an IAC system. For instructions, see 26119, Configuring IAC with the Gateway Configuration Console.
2. On the control system, create a Remote System data instance provides information about the remote system. See About Remote System data instances.
3. On the remote system, open the rule for the case type you want to make available to the control system, and configure the Advanced tab. See Case Type form — Complete the Advanced tab.

On the control 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. Click the + Add Case Type link in the Case Types heading to open the Create Case Type dialog.
2. Expand the Advanced Settings area.
3. Select the Remote Case type checkbox.
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. In the Derives From field, choose the class this case derives from by clicking () or create this class by clicking (). By default, new case types inherit from Work-Cover-.
6. Select an (control) application RuleSet and Version in the RuleSet and Version fields.
7. 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 Rename and Open.

The Processes, Details , and Specifications tabs do not contain remote case type information, which resides on the remote system.

After you create the remote case type rule, configure the Remote Case Configuration tab. See Case Type form — Completing the Remote Case Configuration tab.

FCM systems can be chained; that is, a control system can also be employed as a remote system.

If this case type has only one parent, it is promoted to the top-level. Use the Add option (Use Existing setting) to configure it as a subcase type for another parent.

This option does not appear if this is a top-level case type.

Select Show in New Work menu so that all starter flows for this case type appear in the New work menu on the Case Manager and Case Worker portals. Typically, you designate top-level processes for this menu.

When you create case types, the default settings are as follows:

• Subcase — Show in New Work Menu. Flows do not appear in menu.
• Top-level — Remove from New Work menu. Flows do appear in menu.

Your selections automatically update the Show in New Work Menu checkbox on the Work Types array on the Application rule form's Details tab.

As a best practice, use this option rather than updating the application rule.

Item

Description

Select to add or remove supporting processes and to specify when they start (manually or automatically). In the Supporting Processes dialog, do the following:

1. Select a flow that can be added to an open case created by a previous flow execution.
2. Select either or both:

– Manually start — Select to allow the caseworker to start this process from a user form or from the My Cases tab on the Case Manager or Case Worker portals.

When you select this option, the system automatically adds an area named Supporting Process Settings on the Flow rule form's Process tab. These settings enable the system to automatically route assignments to operators or workbaskets when the supporting process is added to the flow. See Flow form — Completing the Process tab.

Users can start supporting processes () in the Other Actions > Add Work submenu on user forms.

When — Optional. Identify the When Name key part of a when rule that controls the conditions under which users can start this process.

– Automatically start when parent case starts — Select to automatically start this process when the parent case starts. Select if you want the system to start the process when the case is created.

When — Optional. Identify the When Name key part of a when rule. If this rule evaluates to true when the parent case starts, this process also starts.

3. Parameters — This array appears when this process is automatically started. For the parameters defined on this Flow rule form's Parameters tab, enter values that you want this flow to use.

4. Click OK to close this dialog, update the Supporting Processes area on the Case Type rule form's Processes tab, and save the rule. See Case Type rules — Completing the Processes tab.

Optionally, add supporting processes using the Add Process menu in the Case Type tree. Use this item to configure their start behavior.

Select to open the Appearance pop-up dialog. Click the radio button next to the image you want, and click OK to close the dialog and save your edits.

An image specified in the Icon field for this case type on the Application rule form's Details tab overrides this setting.

Select to specify one or more target numeric property values and the input property values in one or more of its subcases. These settings also appear on the Case Type rule form's Calculations tab. See Completing the Calculations tab.

A dependency relationship exists when a dependent case type can automatically instantiate only when one or more other case type instances (under the same top-level case type) are created, completed, or reach a specified work status. You use this item to define that relationship.

Using the parent case type's Instantiation setting, you select the Upon Dependency Fulfillment as the automatic instantiation option for the selected subcase.

Select to create one or more dependency definitions for this case type. In the Define Dependencies dialog, complete the following fields.

Click () to add a row and specify another dependency relationship. All enabled dependencies must be satisfied in order to instantiate a case.

You can also employ case types to define mid-flow dependencies using workbasket assignments of type Dependency. See Process Modeler — Editing Assignment shape.

Altering case type dependency relationships

Dependency data is stored on Page Group pyDependents in the top-level case type rule. Be careful when changing the case type hierarchy, which can alter dependency relationships.

Example 1

If you promote a subcase type a top-level, all of its dependent relationships are deleted.

Assume a subcase type named Ship Order has a dependent relationship with its peer Package Order under their parent case type Equipment Request. If Package Order is removed from its parent and made a top-level case type, the Ship Order relationship is also removed. The row in its Define Dependencies dialog, and the dependency data in Equipment Request, are deleted.

Example 2

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

Using the above example, assume you add top-level Equipment Request as a subcase type beneath top-level New Hire. The dependency data for subcase types Package Order and Ship Order is copied from New Equipment to New Hire. The New Equipment data is deleted.

Select to define the propagation of properties (not property definitions), such as work parties and descriptions, from a case to its subcases. In the form, declare one or more property-set statements. They are invoked at runtime when performing an add-to-cover action such as adding a subcase to a case. The system checks the case type rule for its parent case type and searches for any defined propagation. For an example, see About data propagation below.

Because the system does not create property definitions, the properties do not appear in the Application Explorer.

You can also make this configuration using the Data Propagation button on the Case Type rule form's Processes tab.

Select to create and edit a work item service level rule for this case type. The current goal and deadline intervals appear in the My Cases tab on the Case Manager and Case Worker portals, and on the work summary section on user forms. Do the following:

1. In the Goals and Deadlines for (case item name) will be calculated from the start of: field, define when the starting flow's goal and deadline countdowns begin. One of the following events starts the count:

• Me — When the user manually starts this case's flow.
• My Parent Case — When the parent case starts.
• My top-level case — When the top-level case starts.

2. Select Goal time from Start and Deadline from Start, in days, hours, minutes, and seconds.
3. Click OK to close this dialog, update your edits to this case type's service level rule, and save it.

The first time you use this option, the system creates in this case type a service level rule named .pyCaseTypeDefault. The system also creates a data transform. pyDefault (if it does not already exist) so that .pySLAName is set to .pyCaseTypeDefault. This setting ensures that the .pyOverallSLA flow uses this service level rule. If a transform rule already exists in this class, the system adds the SLA setting. See How to set a service level for a work item.

Select to determine how and when subcase instances are created for each subcase type. The Instantiation pop-up dialog contains the following columns.

Covered Work Type

The name (as it appears on the case types tree) of a case type included in the Coverable Work Types array on the Case Type rule form.

Specialization

The name of a specialized case type that is included in the array.

Settings

A subcase can be created (instantiated) automatically, manually, or both. Select the following:

• Manual instantiation — A user can create an instance of this case type by selecting its name from the Other Actions menu in a user form. Optionally, enter a when rule in the Permitted When field. If it evaluates to true, the user can create this subcase case.
• Automatic instantiation — The system automatically creates this subcase. Select one of the following:
  
  – Upon Parent Case Start — The subcase begins when the parent case type is instantiated. Optionally, enter a when rule in the Permitted When field.
  
  – Upon Dependency Fulfillment — The subcase begins when the settings defined in the Dependencies item for this case type are met.

Both methods (automatic and manual) and Upon Parent Case Start are selected by default.

Optional. Also specify:

• Required for resolution of Loan — .Select if an instance of this subcase type must be created and resolved in order to resolve its parent. Default is not required (empty checkbox).

  For complex conditions, such as requiring resolution of two out of three instances, set up tickets on the relevant assignment shapes.

• Number of Instances Allowed — Limit the number of subcases of this case type that can be created and left unresolved.

If you are extending an existing application, specify the Required settings for subcase types as needed.

Click OK to close the dialog, update the Coverable Work Types area on the Case Type rule form's Processes tab, and save the rule. See Case Type rules — Completing the Processes tab.

Select to edit the fields in the work parties rule. Click OK to close the dialog, update the work parties rule, and save it.

If a work parties rule is specified in the Case Type rule, that rule becomes the default for any starting flows in that work type, overriding any work parties rule referenced in the Flow Rule form's Processes tab.

• Cover or be covered by other base or specialized case types.
• Be auto-instantiated (the system copies the circumstanced property onto the subcase).
• Use attachment categories and auto-attach functionality.
• Use the Stages display.
• Be used in Add Work submenus.
• Employ data propagation.

Select to create specialized case type rules. In the Specialization pop-up dialog, do the following:

1. Select a single value property in the Define new specialization for <case type name> on field (listed by the Description label on the Property rule form).
2. Beneath the property value area, click the Add Row icon ( ).
3. Enter a value that is consistent with the property type, or select one of the property's Table Type values.
4. Optional. Select the Create a Starting Process? checkbox so that the system creates a non-circumstanced copy of the starter flow Work-.pyStandardCMAssignment for this specialized case type. The name is a concatenation of the word "Start" and the property value. The flow does not appear in the Starting Process list on the specialized Case Type rule form or on the case types tree. The flow appears as non-starting on the Application Explorer.
   
   
   
   You can test these flows using the Run icon () on the Flow rule form.
   Add the flows to the Starting Processes list on the circumstanced Case Type rule form's Processes tab so that users can add specialized cases ( ) from the Other Actions > Add Work submenu on user forms. Add the flows to the Supporting Processes list so that they can be started () on the submenu.
   
   
5. Add another row to specify another value.
6. When finished, click OK to close the dialog and create the specialized copies. They appear on the case types tree, indented beneath the base rule node.
   
   
   The system copies the base rule's Starting Processes list to the specialized case type.
   
   About starting flows and specialized case types
   When you add the specialized case type's starter flow to the rule form's Starting Processes list, the flow still appears as a non-starting flow in the Application Explorer, and does not appear in the Case Designer tree. You cannot add these starter flows to the New work menu.
   
   When added to the list on the base Case Type rule form, this flow appears as a starter on the Application Explorer, on the case types tree next to the specialized case type name, and in the New work menu (if configured on the base type).
   
7. In the case types tree, click a specialized item to populate the Case type tab panel, or to access its Action menu.

If the base rule has a parent, the system does not automatically update the Coverable Work Types list on the parent Case Type rule form's Processes tab. You must manually add the specialized versions as described in Case Type rules — Completing the Processes tab.

To configure a specialized version as a parent, open its Case Type rule form (use the Option action item on the tree) and add the child case types to the Coverable Work Types list.

The Details tab for specialized case types that are not parents is limited to Supporting Processes and Stages . If it is a parent, the Data Propagation and Instantiation items also appear . The Action menu items in the tree are Open and Show in New Work Menu.

As a best practice, use the Specialization option to circumstance the case type. You can circumstance the base rule by template, date property, or date range using the Save As form. However, the copy must also use a property value in order to work with the automated case management features described above. Copies that are circumstanced by date, date range, or template values are displayed on the tree in bold typeface beneath the base case type.

For an example, see PDN article 26442 When and how to use case specialization.

The number of stages defined for this case type. Stages are work-status based "Where-am-I" graphical display on user forms. A horizontal array of read-only chevron images ( ) presents the user with a high-level view of the individual tasks that must be performed in order to resolve the case. The array provides a breadcrumb trail; highlighted chevrons indicate stages that have been completed.

To enable the functionality described here, include the Work-.pxWhereAmIChevronView section in your work harness. (See PDN article 26440 How to use stages to present the chevron view of work item status.)

A stage is:

• Represented by a status group field value (Work-.pyStatusGroup), or text constant that appears as a label on a chevron.
• Associated with one or more work status field values (Work-.pyStatusWork).

Stages are also defined on the Stages tab on the Case Type rule form. See Case Type rules — Completing the Stages tab.

Select to create or update the stage display.

1. Stages: list — Use this list to configure the number, order, and names of the stages you want to include in the display. By default, there are three stages identified by text constants. A preview appears at the top of the form.
   In the first field, select a field value with a Field Name key part of .pyStatusGroup and an Applies To class of this case type, or enter a text constant. This value labels the chevron.
2. To add stages, click the Add Row icon ( ) beneath the preceding stage.
3. Change the mouse pointer focus to preview the chevrons and their labels
4. Click a chevron to display a Status Values list (.pyStatusWork values) associated with this stage.
5. Select a work status value. Click the Add Row icon ( ) to add values.
6. Click OK to close the dialog, update the Stages tab on the Case Type rule form, and save the rule.

You cannot use a stage name (text or field value) more than once, or assign a work status field value to more than one stage.

You can customize these standard rules by copying them into the case type's Applies To class. Retain the names OnAdd or Validate for the Validate Name key part.