Case Type rules
Completing the Processes tab

Field

Description

Use the Parties item on the Case Designer Details tab to update the work parties rule.

Select a flow to designate it as a starting process. All inherited starting and non-starting flows of this case type, and starting flows from the inherited case types, appear. When you enter at least one flow, this case type rule – not the Creates a new work object? checkbox on the Flow form's Process tab – defines the starting processes. The system disables the checkbox on all Flow rule forms in this case type; flows not in the list are designated as non-starting processes. If you leave this list empty, use the checkbox on the Flow rule form to configure starting processes.

See Flow form – Completing the Process tab.

Select Actions > Run to run the flow.

Note the following:

• If this case type is covered, enter a starter flow so that users can create cases ( ) in the Other Actions > Add Work submenu on the parent case user forms.
• When you enter a non-starting flow in this field, the system enables the Work Object Creation Settings area on the Flow form's Process tab.
• If this case type is listed on the Application form's Details tab, flows in this list appear in the Create menu on the Case Manager portal. You can override this behavior using the Remove in New Work Menu menu option in the Cases Explorer.
• When you create a case type either in the Cases Explorer or in Application Express, the system generates a default starting flow and populates this field.

Case lifecycle management

It is a best practice to use the Stages and Processes tab on the Case Designer landing page to develop case processing. Use the stages and steps in your configuration, rather than starting processes, to define the case's processing behavior.

If you add stages for a case type, the system automatically creates an instance of pyStartCase in the case type and adds it to the Starting Process list. This flow is necessary to initialize the first stage and stage processing. You can configure work object creation settings such as making a case a temporary object, looking for assignments to create, and so on from the pyStartCase form. If there are stages defined for the case type and you remove the flow from the list, the system automatically adds it back when you to save the case type record.

If you remove all the stages from the Stages and Processes tab, pyStartCase remains in the list but is not implemented.

The default short description for pyStartCase is Create <case type short description> Case. This name appears in the Case Designer and Case Manager portal Create menus.

Specialized starting processes

If this is a specialized (circumstanced) case type rule, you can specify starting processes independently of those defined in the base case type's Starting Process list. Specialized starting processes do not affect the Creates a new work object? checkbox on the case type's Flow rule forms. For example, a non-starting flow entered here does not appear as a starting flow in the Application Explorer, or as a starting process on the case types tree. However, the flow enables the user to create a specialized case from the Add Work menu.

When creating a specialized case type using the Specialization item on the Case Designer Details tab, select the Create Starting Process? checkbox to automatically create a starter flow for the new version. This flow does not appear on the case types tree and appears as a non-starter flow on the Application Explorer.

Processes from imported case types

When you use Application Express  or the Cases Explorer Import menu action to add a case type from a built-on application, the system automatically populates this array with the inherited case type's starting processes. They are referenced but are not imported into your current application. You can reuse the processes or copy (Save As) them into your application.

When you enter at least one flow, the system adds the Supporting Processes Settings to the Process tab on the Flow rule form (in this case type rule's Applies To class). Use the settings to automatically route available assignments to available operators or workbaskets when the flow starts. See Flow form — Completing the Process tab.

Use the Supporting Processes item on the Case Designer Details tab to update these values. You can also use the Add > Process menu on the case types tree to update this list.

On user forms, 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 caseworkers can start this process.

When — 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.

Select a class derived from Work- or Work-Cover- class in the current application that you want to include.

Note the following:

• If you intend to aggregate properties in a class using the Coverable Work Types list on the Calculations tab, add the class here.
• If Temporary object? is selected on the flow Process tab, the flow will not be available.

Specialized case types

You can circumstance-qualified (by property) case type instances using the Specialization item on the Case Designer landing page Details tab. See Case Designer landing page.

Referred to as specialized case types, these versions can:

• 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.
• Used in Add Work submenus.
• Employ data propagation.

If you enter in the Coverable Work Types field a subcase type that has specialized versions, a second field appears.

Select one of the following:

• Any Specialization — Cover all specialized versions of the selected subcase type.
• <Specialization name and value> — Select the specialized version you want to cover. To cover other versions individually, add a row ( ), enter the same subcase type in the first field, and select another version in the second field.

Permitted When: Optionally, identify the When Name key part of a when rule. If this rule evaluates to true, the user can create this subcase.

Select one of the following:

• Upon Parent Case Start — The subcase begins when a parent case type is instantiated. Optionally, enter a when rule in the Permitted When field. If this rule evaluates to true when a parent case is created, this subcase is also created.
• Upon Dependency Fulfillment — The subcase begins when the conditions in the dependencies definition for this case type are met. Use the Dependencies item on the Case Designer landing page to define the dependency conditions.

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

Use the Supporting Process item on the Case Designer landing page Details tab to update these values.