Workflow governance
Distinguish code-owned operational flows from protected or tenant-created human workflow definitions, then inspect immutable versions, instances and task projections.
Screen orientation
Tenant administrators govern definitions. Instance/task visibility remains tenant-, site-, classification-, role- and assignee-scoped by the server.
Operational flows is a read-only documentation catalogue. Human workflow definitions provides the bounded designer/version history. Instances & tasks shows persisted state and executable projections.
Field reference
The entries below describe the current screen controls and read-only values. They do not relax server-side validation, site scope, classification handling or required independence in a governed decision.
| Field or value | Control | Required or shown when | How to use or read it | Result |
|---|---|---|---|---|
| Workflow governance sections | Tabs | Required navigation. | Choose Operational flows, Human workflow definitions or Instances & tasks according to intent. | Keeps three workflow layers distinct. |
| Search operational flows | Search | Optional. | Find the code-owned end-to-end flow and its public handbook. | Filters documentation only. |
| Workflow name · Workflow key · Purpose and scope | Definition fields | Required for a new generic human definition. | Use a stable key and bounded human-work purpose. | Creates the registration/version identity. |
| State label · State key | Repeatable state controls | At least one initial and terminal outcome are required. | Define bounded human states. | Builds the immutable graph. |
| Action label · Action key · From · To | Transition controls | Required per transition. | Define human handoff labels and connected states. | Builds the versioned transition graph. |
| Responsible role | Role select | Required per transition. | Choose an exact existing role. | Controls task projection eligibility. |
| Must be a different person from | Maker-checker dependency | Optional but authoritative when set. | Select only a directly preceding action dependency. | Enforces named-person separation. |
| Version history | Read-only table | Derived. | Use version/checksum/state to identify active versus retained definitions. | Explains immutable definition lineage. |
| Instance state summary · Open workflow tasks | Read-only tables | Derived. | Inspect persisted version-pinned work and eligible transitions. | Shows human task state without executing unknown domain actions. |
Actions and effects
When to use: For a bounded GENERIC human workflow.
What it does: Creates immutable version 1 in DRAFT; callbacks/actions are rejected.
When to use: After controlled review of a definition.
What it does: Activates a new version for future instances; existing instances stay pinned.
When to use: For a protected executable task.
What it does: Navigates to the code-owned action; the catalogue itself does not execute it.
Lists and states
- Operational flow catalogue lists code-owned end-to-end processes and documentation.
- Definition/version and instance/task tables retain immutable graph and runtime state separately.
Authority boundary
Generic definitions orchestrate human states only. They cannot execute tenant JavaScript, SQL, callbacks, arbitrary endpoints, inventory postings, MRB consequences or other domain commands.