|
|
Complete the Processes tab to define this case type's processes, and its parent/child relationships.
Many of the fields on this tab can be configured using the Case Designer landing page, and are noted below. Where appropriate, your edits in the landing page also update and save this rule (can be in a locked RuleSet version).
Field |
Description |
Appearance | Choose an icon to appear beside cases of this type. Click Edit to replace the default image with one of the listed icons. |
Work Parties Rule | ![]()
|
Starting Processes |
See Flow form – Completing the Process tab. Select Actions > Run to run the flow. Note the following:
Case lifecycle managementIt 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.
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 processesIf 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? check box 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.
Processes from imported case typesWhen 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.
|
Manually start | Select to allow the caseworker to start this process from a user form or the My Cases tab on the Case Manager and Case Worker portals.
On user forms, users can start supporting processes in the Other Actions >Add Work submenu on user forms.
|
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.
|
Parameters | Optional. Appears when Automatically start when parent case starts is selected. The parameters in the array are defined on the flow's Parameter tab. Enter values that will appear when the property appears on a work form. |
Coverable Work Types | This array appears only if the Applies To class for this rule is derived from Work-Cover-. Classes in this array appear as items in the Other Actions >Add Work submenu available in the action section on Perform, Update, and Confirm user forms. Users select an item to create a case.
Note the following:
![]() 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:
If you enter in the Coverable Work Types field a subcase type that has specialized versions, a second field appears.
|
Manual instantiation | Select so that users can instantiate this case type from the Other Actions menu on a user form, or from the My Cases tab on the Case Manager and Case Worker portals. Selected by default.
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. |
Automatic instantiation | Select so that the system automatically creates subcases for this case type. Selected by default.
Select one of the following:
|
Max Instances | Optional. Enter a positive numeric value to indicate the maximum number of instances of this case type that can be created (count includes resolved cases). You can only set this value on the Case Type rule. |
Required | Optional. Select if an instance of this subcase type must be created and resolved in order to resolve its parent. Default is not required (empty check box).
You can only set this value on the Case Type rule.
|
Data Propagation | Optional. Enabled when a Coverable Work Type is defined. Click to open the Data Propagation modal dialog. 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. You can also apply a data transform for each subcase. The property-set statements and data transform 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.
|
![]() |
action section, cover, instantiate |
![]() |
About flows |