Use the Cases Explorer to add subcase types to a parent, add supporting processes to a case type, or create top-level create types.

Adding a subcase type

Right-click a case type , or click the next to the case type node, and select Add from the menu. The Case Designer: Add dialog appears.

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 Explorer and in the Short Description label on the Case Type form. The name is concatenated and used as the Class Name key part. See Class Rules — Completing the Create New or Save As form.
• Reuse an existing subcase type not already covered by this case type — Select the Use Existing check box. In the Name field, select a case type in your application. Any existing subcase relationships remain intact. 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). See About Dependencies.

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

• Derives From (Directed). Choose the class this new item derives from for directed inheritance. By default, the class created for the new case type will inherit from Work-Cover-.
• Derives From (Pattern). Choose the class this new item derives from for pattern inheritance. By default, the class created for the new case type will pattern inherit from the current work pool.
• RuleSet. Select the new item's RuleSet.
• Version. Select the RuleSet version.
• Create Starting Process. Clear this check box 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.

As a best practice, use the Cases Explorer, not the underlying case type records, to manage your case management structure.

About standard rules used in case types

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

• Class — Created in the work pool you are extending; inherits from Work-Cover-. The Class Name key part is the concatenated name you entered in the Add dialog.
• pyDefault case type record — For subcase types, adds this case type on the parent's Case Type form's Coverable Work Types list. The default short description is the text you entered in the Add dialog's Name field.
• pyStartCase flow — The flow is listed as a default starting process on the Case Type form's Processes tab. Used in case lifecycle management, this flow is used by the first stage (as defined on the Case Designer Stages and Processes tab) to create a case and initializes processing. The default short description is Create <case type short description> Case. This name appears in the Create menu on Case Designer and Case Manager portals.
• pyCaseManagementDefault work parties — Copied from the Work-Cover-.pyCaseManagement instance. By default, this value populates the Work Parties field on the flow 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).

About Federated Case Management

Federated Case Management (FCM) uses Internet Application Composer (IAC) connectivity to link PRPC applications in a federation. FCM features integrate different PRPC systems, allowing a user logged into an application (the user’s local system – see Local system) to create, open, and work on cases in a different application from within his current application portal, without having to log in to another system or open another browser window. On each application in a federation, you select case types to make available to other applications as remote case types, so they can be viewed and accessed in other systems. For more information, see Federated Case Management.

The FCM user interface allows users on their local system to:

• Use theNewmenu on the Case Manager or Case Worker portals to create and work on remote cases.
• Create and work on remote cases in their local 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, perform the steps described in the PDN articleSetting up and configuring Federated Case Management - Pega 7.1.

On each 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. In the Case Explorer click the menu arrow and select Add a case type. The system displays the Case explorer: Add dialog.
2. Expand the Advanced Settings area.
3. Select the Remote Case type check box.
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. Expand the Advanced Settings area.
6. In the Derives From (Directed)field, choose the class this case derives from for directed inheritance. By default, the class created for the new case type will inherit fromWork-Cover-.
7. In the Derives From (Pattern) field, choose the class this new item derives from for pattern inheritance. By default, the class created for the new case type will pattern inherit from the current work pool.
8. Select an application RuleSet and Version in theRuleSetandVersionfields.
9. 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 Open and Rename.

The Stages & Processes, Details , and Specifications tabs do not contain remote case type information; this resides on the remote system.

After you create the remote case type rule, configure the Remote Case Configurationtab. Click thecase type definitionlink in one of the tabs. 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.

You must use the Remote Case type option to create remote case types and case type rules. You cannot create these rules using the Application Explorer or copying an existing rule. Be careful not to delete remote case type rules.

Creating a top-level case type

To create top-level case types in your application: in the Cases Explorer

1. Select Case Types > Add a case type to open the Cases Explorer: Add dialog.
2. Leave the Use Existing check box blank because you are creating a new case.
   
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 link to add subcases by enter a valule in the Parent field. Adding a subcase type for details.

About case ID prefixes

As a best practice, when you create case types, use unique and meaningful case ID prefixes so that when displayed in work lists and user forms, users can quickly associate cases with their case types.

The system determines a case ID prefix in the following order:

1. The value in the Work ID Prefix field for this case type on the Details tab on the Application rule form.
2. The prefix setting for .pyWorkIDPrefix in the .pyDefault data transform of that work type. Note that when you create a new case type in Case Designer, you must manually add a data transform; the Application Express generates the rule with the prefix already defined.
3. If neither of the above is true, the Work-Cover-.GenerateID activity uses "C-" as the default prefix (also used for ad hoc work).

See Understanding work item IDs.

	case management, landing page, subcase,top-level case type, ad hoc work, cover, folder, case, instantiate, case type, Federated Case Management
	About Case Type rules Process and Rules category — Case Management Gallery