Process definition lifecycle#
Workflow separates process registration, draft persistence, publication and activation. This gives authors a place to revise a process while running instances continue against the exact version on which they started.
A process registration has a stable identity, display name, owner and scope. Its draft revisions contain the BPMN XML, diagram layout and supported extension properties. Published versions retain immutable source and compiled execution content. An activation binds an approved published version to a tenant, environment and permitted start contract.
Lifecycle records#
| Record | Purpose | Change behavior |
|---|---|---|
| Process registration | Identifies the business process and groups its versions | A rename preserves the stable key |
| Draft revision | Stores editable diagram and properties | Expected revisions prevent stale overwrites |
| Published version | Pins executable content and its dependencies | Immutable after publication |
| Activation or start binding | Selects the version available to new starts | Explicit revisioned update |
| Instance | Executes the selected version and bindings | Retains its original pins and history |
Registering a participant capability is a different operation. It describes what a service can do. Registering a process describes how approved capabilities and human responsibilities compose into business work. Neither operation activates execution by itself.
Authoring sequence#
- Open Processes and register a stable process key with its owner and descriptive metadata.
- Select approved service or human bindings. Configure variables, input/result mappings and explicit outcome paths.
- Save the draft. The server persists the acknowledged revision, including diagram layout.
- Choose Validate saved revision. Correct unsupported elements, incompatible contracts or missing bindings before publication.
- Choose Publish saved revision. The publication service recompiles the saved content against the current approved catalog.
- Use Activate / update a start binding to select the exact published version and permitted start kind.
Publication creates no process instance. Activation makes a selected starting rule available, but the actual start still requires an authorized request or eligible event.
Concurrency and lost responses#
Draft editing uses optimistic revision checks. If two editors save the same revision, one succeeds and the other receives a conflict. The rejected editor must reconcile with the acknowledged server revision rather than silently overwriting it.
Authoring operations should not be treated as though they all provide the durable runtime command protocol. After an uncertain save, publication or activation response, inspect the current record and revision before deciding whether another mutation is needed. Preserve the user's unsaved content during that reconciliation.
Dependency pinning#
Published execution content records the compiler and BPMN profile together with schema and catalog bindings. Approval of a later manifest does not rewrite a published plan. A service or human binding must remain compatible with the selected role, input schema, result meaning, tenant and policy.
At first ingress, Workflow retains the selected activation and process version. A replay after a newer version becomes active must return to the original start decision instead of selecting the new definition and creating another instance. A new activation applies to future eligible starts, while existing instances preserve their own version and history.
Retirement and revocation#
Retirement removes a process or catalog entry from new composition or starting eligibility while retaining referenced history. It is distinct from runtime authorization revocation. A pinned binding does not grant permanent permission: current enrollment and authority can block a new dispatch, claim or completion.
Already-dispatched operations still require authoritative outcome reconciliation. Removing a permission cannot erase an external business effect. Retain referenced definitions, schemas and receipts for the declared execution, retry and recovery horizons.
Authoring, publication and activation use separate permissions: process.write, process.publish and process.activate. UI visibility does not replace those server checks. For the executable elements and limits that publication enforces, see the BPMN profile.