To establish consistent processing and expedite creation of workflow definitions across a group of related processes, you can create workflow definitions that inherit the workflow maps, data fields, attachments, workflow group definitions, and other properties from other previously defined workflow definitions. This means that you can define common characteristics in workflow definitions at a high level in the class hierarchy and automatically pass these characteristics to subsequently derived workflow definitions.
The base class for all workflow definitions is the FileNet-provided WorkObjectEx. From WorkObjectEx, workflow definitions inherit system data fields, the Terminate submap and the Malfunction submap.
NOTE While all workflow definitions inherit from the FileNet-provided base class, you can enable or disable inheritance from other workflows. See "Preferences - Workflow" in the online Help for Process Designer for information about this option. See the example below to understand the consequences of disabling inheritance in workflows that already contain inheritance functionality.
When you create a new workflow definition based on another workflow definition, the new workflow inherits the following from its base workflow:
Workflow map | The inherited main map is automatically overridden in the new workflow by a blank main map with only a Launch step. You can reactivate the inherited main map by deleting the main map in the current workflow. |
Submaps | Inherited submaps are read-only. You can modify an inherited submap by overriding it. |
Data field, attachment, and workflow group definitions |
Inherited fields, attachments, and workflow groups may not be deleted, but initial values and descriptions can be changed. |
Workflow deadline and reminder | Workflow deadline and reminder are initialized from the base workflow but can be changed. |
Milestones | The inherited milestone level and message can be changed. |
Event log and roster | The inherited designations for event log and roster can be changed until the workflow is transferred. |
Condition Identifier | The value is initialized from the base workflow but can be changed. |
Partner link and XML schema | An inherited partner link or schema cannot be changed. |
XML data field | The value and description of an inherited XML data field can be changed. |
Incoming Web Services attachment folder | The folder where incoming Web Services attachments will be stored can be changed. |
Rule set names | For an inherited rule set, the Asynchronous setting can be changed. |
Email notification preference | The value is initialized from the base workflow but can be changed. |
Inherited items—main map, submaps, data fields, attachments, workflow groups, and so on—are read only in the workflow definition. However, you can override an inherited item by redefining it. For example, you can override an existing map using Create Map on the Tools menu. If you subsequently delete the overriding map, the inherited map is reactivated.
NOTE If you override an inherited field, you can change only the initial value and description, not the field type.
The illustration below shows how items are inherited and might be replaced at some level in the hierarchy.
Workflow-A is intended as a base for future workflow definitions. Submap-a1 and submap-a2 are designed as general purpose functionality to be used in all workflow definitions derived from this one, and field-a1 and field-a2 are used in these submaps.
Workflow-M uses Workflow-A as its base workflow, inheriting the maps and data fields. Workflow-M uses its own main map (main-M), adds submap-m1 and field-m1, and replaces submap-a1 with its own version of that submap.
Workflow-N also uses Workflow-A as its base workflow. Workflow-N uses its own main map (main-N) and adds its own submap and field. It uses the original submap-a1 inherited from Workflow-A.
Workflow-R uses Workflow-M as its base workflow, inheriting maps and fields from Workflow-M. In Workflow-R, the default main map (main-R) is deleted and the inherited main-M is the main map. Submap-m1 is replaced with a new version, and field-r1 is new.
If workflow inheritance is disabled in Workflow-R, the inherited maps and fields are no longer accessible, but the references remain in the workflow definition. The inherited main-M (main map) is replaced by main-R. Submap-m1 overrides the inherited submap-m1 so it remains. Field-r1 was created in Workflow-R.
TIPS
If you subsequently re-enable inheritance, the inherited items (submaps, fields, and so on) will become accessible, although the main map (in this example, main-R) will continue to override the inherited map, and F_Trackers will continue to override an inherited F_Trackers, if any. You can delete the overriding main map and F_Trackers if you wish to use the inherited main map and F_Trackers.
NOTES
See Inheritance example for a description of how to use inheritance in derived workflows.