Workflow inheritance
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 Content Cortex-provided WorkObjectEx. From WorkObjectEx, workflow definitions inherit system data fields, the Terminate submap and the Malfunction submap.
When you create a new workflow definition based on another workflow definition, the new workflow inherits the following from its base workflow:
| Inherited workflow properties | Description |
|---|---|
| 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 cannot 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.
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.
- If you disable workflow inheritance in a workflow that inherits
maps, fields, and other properties from another workflow, the base
map of that workflow will be reset to WorkObjectEx and all items inherited
and not overwritten from the previous base workflow will no longer
be available. If these items are referenced, such as by a submap step,
validation errors will occur.
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 want to use the inherited main map and F_Trackers.
- If the base workflow for Workflow-R is switched from Workflow-M to Workflow-N, main-N becomes the main workflow map. Submap-m1 remains because it overrides the inherited submap-m1.
- In Workflow-R, main-A, and the original form of submap-a1 are not inherited into Workflow-R—only the items active in Workflow-M are inherited.
- Workflow-R does not add submaps accessible from the main map (main-M) because main-M is read only; instead, submap-m1 is modified for the desired functionality. If the workflow author deletes the modified submap-m1, the submap-m1 inherited from Workflow-M is reactivated and cannot be deleted.
- The inherited items in a derived workflow definition reflect the properties in its base workflow at the time the derived workflow is created. If the base workflow is changed and transferred to the workflow system database, any derived workflow definitions will remain unchanged until you open a derived workflow definition and re-transfer it.