Process Management
A process record is a governed description of how work is done. Like a controlled document it has owners, a revision chain, an approval lifecycle and a record-level authority matrix — but instead of a file, its content is structured: steps, responsibilities, risks, opportunities, stakeholders and expectations.
Process records and controlled documents solve different halves of the same problem. A document says what the procedure text is; a process record says who does what, in what order, with which risks attached.
Core fields
- Code — auto-generated. Kept the same across the whole revision chain.
- Name — the process title.
- Process step type — classifies the process. Must be a step type whose category is Process. See Process Step Types.
- Parent process — optional, building the process hierarchy.
- Owner — the accountable identity.
- Purpose — why this process exists.
- Scope — what it covers and what it does not.
- Critical success factors — what has to go right.
- Cost / duration — the planning figures.
- Revision number / version number — see below.
- Review scheduling — when the process is due for re-examination.
Process-local content
Seven collections describe the process itself. None of them drives a task or a lifecycle action — they are descriptive and planning data:
| Collection | Contents |
|---|---|
| Steps | The ordered list of steps, each optionally with an executor. |
| Responsibles | RACI parties — responsible, accountable, consulted, informed — optionally scoped to a specific step. |
| Risks | Risks attached to the process or to a step. Each carries impact, probability and score. |
| Opportunities | The same shape as risks, for improvement opportunities. |
| Stakeholder expectations | What stakeholders expect, with impact/probability/score. |
| Stakeholders | Who the stakeholders are. |
| Attachments | Supporting files. |
Impact, probability and score on risks, opportunities and expectations are three independent fields. The score is not calculated as impact × probability — it is entered directly, because that formula could not be substantiated as a universal rule.
Steps and executors
A step is a junction between the process and a process step type, with a display order and at most one executor.
The referenced step type must have its category set to ProcessStep and must not be flagged as "cannot be linked to a process". These are enforced when you save, not just hidden in the picker.
Revisions
A published process is revised rather than edited:
- Start revision opens a new row in the same chain — same code, revision number incremented, all twelve collections deep-copied.
- The source row is untouched and stays published until the revision is approved.
- Approving the revision supersedes the previous published row, which moves to inactive.
- Only one draft may be open in a chain at a time.
Copy detail is a different operation: it produces a brand-new, independent process with its own new code — not a revision.
Checkout locking
A process can be locked while somebody works on it, preventing concurrent edits. The record shows who holds the lock and when it was taken.
The authority matrix
Beyond the routing matrices, a process carries a record-level authority matrix that governs who may act on this specific record. This is separate from the routing matrices, which decide who gets tasks — the authority matrix decides who is allowed at all.
Deleting
Deletion is allowed only while the process is in the draft category. A published or inactive process cannot be deleted; supersede or deactivate it instead.