Process and Rules category — Case Management page

Use the Case Management landing page to configure the case type structure and work processing configurations for each case type. You can:

• Construct covering relationships and build new case types using a standard tree grid gadget.
• Add new case types: Creates Class and Case Type rules, and creates a standard starting flow for the new case type.
• Reuse existing case and work types.
• Manage various aspects of work processing, including:
  • Service levels
  • Attachment Categories (and automatic attachments when work objects are created).
  • Automatic and conditional instantiation of covered items when a new cover (case) is created.
  • Mapping roles to object access for your various case and work types.

The Case Type Definitions gadget is organized into a tree structure of case types called cases () and tasks (), which are grouped by work pools (). The Case Type Definition tree gadget displays your application's cover hierarchy and allows you to configure various aspects of work processing for each case type.

Case types inherit from Work–Cover– and have a Case Type rule defined. A case type can cover or be covered by other case types. In the tree, a covered node (case or task) indents (nests) beneath the covering node. You can also create work types that inherit from Work-, which can be covered. These work types may have a Case Type rule, but the rule cannot be configured to cover other case or work types.

Strictly speaking, a case is to a case type instance. Caseworkers create, view, and work on cases in the Case Management portal.

The tree structure uses three elements to organize the case type relationships:

• Top-level case — Serves as a top-level parent case type within a work pool and is not covered by another case. A work pool can contain more than one top-level case.
• Subcase — A case type that is covered by a parent case type at any level. A subcase instance typically must be created and resolved before the parent case can be resolved. A subcase can also parent other subcases. Unless referred to in the context of its parent/child relationships, a subcase is informally called a case.
• Task — The gadget enables you to add a case type called a task. Its class structure and processing behavior are identical to that of a case type. This term is used only to describe its role within the application. Although a task can be used at any level within the hierarchy, it is most often represents low-level work nested under a parent case type. (Do not confuse case management tasks with task shapes in a flow. )

Click a case type or task in the tree to open its Case Type rule.

Detailed information for each of the above includes:

Column	Description
Name	Name of the case type as entered in the Case Type Definition:Add pop-up dialog.
Show in New work	Indicates whether starting flow names for this case type appear in the list displayed from the New work button () in the Case Management portal. The caseworker uses this button to create a parent case. By default, this option is not selected. If selected, this case type appears in the Application rule form's Work Types list on the Details tab. Use the Show in New Work or Remove from New Work right-click menu options to change the setting, if necessary. V6.2 GRP-23678
Instantiation	When a new case is created, covered cases can be created in one of two ways: Automatic upon parent case start — When a parent case is created, the system automatically creates cases for each coverable class, and then begins their starting flows. New case types default to Automatic instantiation when added to a parent. Manually created by User — The caseworker creates the case in the parent case's work form by selecting the case type name from the Add Work... action drop-down list. Note that even though instantiation is set to Automatic, this work type still appears in the drop-down; the case may also be created manually. Do not confuse these cases with ad hoc work the caseworker creates in the Case Management portal (using the Add Manual Case (or Task) right-click menu options on the Cases tab). If you are extending an existing application, this default behavior may not be desirable. Specify that the Instantiation settings for a case's children as required by your application. Use the Properties > Instantiation right-click menu option to change the setting if necessary.
Required	A check icon () indicates that the parent case cannot be resolved until all the covered cases of that type are created and resolved. When added to a parent, new subcase and task types default to not being Required (empty checkbox) As this may not be desirable when extending an existing application, specify that the Required settings for a case's children as required by your application. Use the Properties > Instantiation right-click menu option to change the setting if necessary.
Max Allowed	Maximum number of cases or tasks of that type that can be added to the parent. If necessary, use the Properties > Instantiation menu option to change the setting.
Attachments	Count of attachment categories defined for each case type. There is no value if the item is a work, not case, type.
Legacy	Indicates that this item extends from Work–, not Work–Cover–; the item can be covered by a case type but cannot cover other work or cases types.

You can sort the table by any of these items.

You can perform the following actions for each case or task by right–clicking the work pool or case type icon in the tree grid, which opens a context menu. The options that appear depend upon the relationships among the case types and each case type's configuration.

Action	Description
Add	Select to add a case or task. Select either: Use Existing. Select the existing parent case or task using the () auto complete options. or New Select Case or Task. Enter a case or task Name. Click OK. When you add a case or task, the system automatically creates a Case Type rule for that case type, and adds a reference to that type in Coverable Work Types list on the parent's Case Type rule form. The system also creates the following standard rules: Class — Created in the work pool you are extending; inherits from from Work-Cover-. OpenDefaults activity — When the user opens any work item in review mode, this activity sets a parameter and causes this activity to use the pyCmReview harness instead of the default Review harness. The process also makes the top case available on the clipboard. Start<class name> starter flow — Copied from the Work-Cover-pyStandardCMAssignment instance. pyCaseManagementDefault work parties rule — Copied from the Work-Cover-.pyCaseManagement instance. By default, this value populates the Work Parties field on the Process tab in the starter Flow rule form. Click () to expand the Advanced Settings: Derives From. Choose the class this new item derives from by clicking () or open this class by clicking (). By default, new objects inherit from Work-Cover-. Choosing another work class RuleSet. Choose the RuleSet of the new item. By default, the new class is associated with the application Version. Choose the RuleSet version. Create start flow. Click () to create a starter flow for this item. Selected by default.
Save As	Create a copies of the class and case type to a different work type name. Underlying rules are not copied.
Rename	Rename the case, subcase, or task as it appears in the tree grid. It does not change the name of the underlying case type rule.
Remove	Detaches this work type from its current covering class.  The system deletes this node from the list of Coverable Work Types on the Processes tab on the covering class Case Type rule form.
Show in (Remove from) New Work Menu	Select this option to indicate whether you want starting flows in this case type to appear in a drop-down list when the user clicks the New work button located in the Case Management portal header. If the case is set to Show in, this case type appears in to the Application rule form's Work Types list on the Details tab.
Properties >	Click properties to edit: Attachments In the dialog, click () to add an attachment to this case or task type. Specify the Description, Type, Category, if it is Required, the File Name, Reference and whether you can Auto Attach it. You can specify Automatic or Required attachments using this gadget: Automatic attachments: You can specify a set of File or URL attachments that will be automatically attached by the process engine when a new case of this type is created. These attachments are available to users viewing the details of a case via the Attachments Gadget embedded on the Case Details screen. Required attachments: You can specify a set of File or URL attachment categories that must be attached to a case before the user is allowed to resolve that case. The system adds a validation error to a case to prevent resolution if an attachment of this category is not present in the case's list of attachments. Goals and Deadlines Click to view and change the Overall Service Level settings for the selected case type. Use the Goals and Deadlines for (case item name) will be calculated from: field to 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 in this application starts Select Goal time from Start and Deadline from Start, in days, hours, minutes, and seconds. When this item starts, the values are displayed in the Work Management portal's tab Calendar tab.V6.2 GRP-17952 Instantiation This choice appears if a case has subcases or tasks. Click to open a dialog in which you modify the creation method for dependent cases or tasks, a when rule associated with the method, maximum instances that can be created, and whether the instance must be resolved before the parent is resolved (Required). Access Roles Click to open a dialog in which you associate an owner with this case type as defined by an access role. You can also create an access role and optionally a workbasket for this case type and its descendents. Note that the access role is only available to subcases or tasks that descend from this case type. By default, case types do not have owners. Select the Deny Access checkbox to prevent the role from accessing work in for this case type. It is a best practice not to deny owner access. When you create an access role and workbasket, they appear in the Access Role gadget. Appearance Use this option to change the icon representing the case or task in your tree structure. The icon also appears in the user work forms and the case manager portal. When the pop-up dialog appears, select the radio button next to the icon you want and click OK. V6.2 GRP-17894 pashm Data Aggregation Complete this form to calculate the sum of a target property values in a case or a subcase whenever the input property values in subcases are updated. See Completing the Calculations tab. V6.2 GRP 22071 Data Propagation Use this form 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. The property-set executes 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 the cover and searches for any defined propagation. Because the system does not create property definitions, the properties do not appear in the Application Explorer. New V6.2 story coming - enabling use of models to transform and map data on the clipboard using models instead of activities - pashm 1/25/11 V6.2 GRP 21015 Parties This option appears if the Case Type rule form has a work parties rule specified in the Work Parties Rule field on the Details tab. Select the option to edit the fields in the work parties rule. 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. V6.2 GRP 21007

As of V6.2, there are four case management-specific harnesses within Work-Cover-:

• pyCMConfirm
• pyNewCM
• pyCMPerform
• pyCMReview

For new case management applications built in the Case Type Definitions gadget, these harnesses are automatically used by the starting flows and the new case types. Use these harnesses as you extend your existing case management application.

By default, assignments in the default case management starter flow refer to the pyCMPerform harness.

The system populates the following fields in the Work Object Creation Settings area on the starter Flow rule form's Process tab:

•  If an assignment is not being performed (Show Harness) — pyCMConfirm
• Harness — pyNewCM
  

Below is an example of a configured data propagation form:

The property in the Set value of field is the child page that you are adding to the cover.

The property in the To value of field is the cover to which you are adding a child.

You can use property-set syntax to set a scalar property (for example, .Customer) on the child to the value of a embedded scalar property from the parent; for example, .pyWorkParty(Customer).pyWorkPartyUri.

In the example, the parent case type is Equipment Setup, and the child is Desk Lamp. The pyFullName and pyWorkPartyUri (email) fields are the definitive values. The values from the member of the pyWorkParty group is subscripted "Customer". The pyWorkPartyUri acts as a URI, which is the identifier used as a reference to establish that two data records are referring to the same party.

The first step to formalizing a case type structure is to add the work type that your application considers to be the top-level case directly to the work pool.

. Do the following:

1. Click the work pool icon , right click, and select Add.
2. In the context menu, select Use Existing.
3. Specify the top level work type.
4. Click OK.This automatically creates a Case Type rule for that work type. It appears as a top-level case under its work pool.

At this point, you have a single case type rule defined, with no coverable work types yet. Right-click the top-level case and choose Add, with Use Existing, and add subcases or tasks to that top level case. The result is a formal case type structure with one top-level case containing two subcases. To add a subcase or task, click a case icon () or a task icon , right click, and select Add.

The Access Roles landing page gadget provides a single place to view, add, and remove Rule-Access-Role-Name rules for your application.

Automatic workbasket creation: When you define a new access role using this gadget, it gives you the option to create a workbasket of the same name. The automatically created workbasket will be created in the same organization, division, and organization unit as the developer that created the new role.

Role deletion: When a role is deleted using this gadget, any corresponding Rule-Access-Role-Obj instances will be deleted also. Optionally, you can automatically delete the corresponding workbasket instance, if it exists.

You can add or modify menu items to the Case Management landing page and Case Type Definition tree by copying the following Rule-Navigation rules in your application:

• pyExtendedCaseManagementLPMenu — The Case Management landing page menu.
• pyCaseTreeExtendedRightClickAction — The right-click menu in the Case Type Definition tree.
• pyCaseTreeExtendedPropertiesRightClickAction — The Properties sub-menu off the right click menu in the Case Type Definition tree. GRP-24365-1 V6.2