Workflow & Policy Inheritance
This article covers the inheritance rules for workflow definitions and for the policy-style settings — suspect links, verification configuration, and variant designations. For the overall model, start with Configuration Inheritance.
Workflow definitions: replace, never merge
Workflows are state machines — statuses, transitions, guards, and effects that depend on each other. Merging two state machines property-by-property would produce a workflow nobody designed, so workflows are the one kind of configuration that is atomic:
- A workflow is identified by its name. Defining a workflow with the same name at a lower tier replaces the inherited definition completely — statuses, transitions, guards, effects, all of it.
- There is no partial workflow override: you cannot inherit a workflow’s statuses and change just one transition.
To adapt an inherited workflow, you have two honest options:
| Goal | Approach |
|---|---|
| A variation of the standard process for this workarea | Copy the workflow into a new name (e.g. requirement-flow-strict) and assign your types to it |
| This workarea’s process genuinely differs | Redefine the same name locally — accepting that you now own the whole definition and parent improvements no longer reach you |
Workflow assignments follow type patching
Which workflow an item type uses is a property of the type, so it follows the normal type patching rules: a workarea can point an inherited type at a different workflow without touching anything else about the type.
Tip: This is usually the better lever. Keep workflow definitions at the global or group tier, and let workareas choose which of the standard workflows each type uses.
Suspect links
Suspect link configuration merges per setting:
- Enabled and the default rule — the closest tier that sets a value wins (workarea over group over global).
- Per-link-type rules — merged by link type: a lower tier’s rule for
verified byreplaces the inherited rule forverified byonly; rules for other link types continue to flow down.
So a group can enable suspect tracking with a sensible default, and a single workarea can tighten the rule for one link type without restating the rest.
Verification configuration
The verification settings (which enumeration provides test verdicts) follow closest-tier-wins: a workarea that sets a verdict enumeration uses it; one that doesn’t inherits the group’s choice, then the global one, then the built-in default.
Variant designations
Variant management settings (whether variants are enabled, and which item and document types act as variant codes, rules, features, and DNA documents) merge per setting with closest-tier-wins. A group can designate the variant types for all of its workareas while an individual workarea overrides just one designation — each setting falls through independently to the tier above, ending at built-in defaults.
Icon library
Icons follow the same spirit: icons uploaded at the global or group tier appear in every workarea below as inherited icons, alongside the workarea’s own uploads. Inherited icons are managed at the tier that owns them.
Summary
| Setting | Granularity of override |
|---|---|
| Workflow definitions | Whole workflow (atomic, by name) |
| Workflow assignment (per type) | Single property on the type |
| Suspect links — enabled / default rule | Single setting |
| Suspect links — link-type rules | Per link type |
| Verification verdict enumeration | Single setting |
| Variant designations | Per designation |