What a review policy controls, and what an empty grant means¶
Audience: quality managers configuring a project.
A review policy is set per project, per document type, on Scope configuration → Review policies (the gear icon). It answers two different questions, and the box is split into two visually distinct sections because conflating them is what used to confuse people.
1. Section A — Workflow defaults for new documents¶
Three role groups — Authors — who may submit, Reviewers — who must approve with the number of approvals required from each, and Releasers (may release).
These are a template: they are copied onto each new document of this type at creation, where they can still be edited, and they freeze while that document is in review. Changing them affects future documents; documents that already exist keep the bindings they were born with.
2. Section B — Standing permissions on this type¶
Three rows in action language — Revise & periodic review, Revoke, Cancel — enforced directly, live, on every document of this type. No copying, no per-document override.
Rejecting is not a row here: whoever may approve may reject. That is a reviewer's right, not a separate permission.
3. Empty means nobody — and it says so¶
Every transition is always on screen with its role multi-select. A row with no role is granted to nobody, and the box renders that as an explicit "⚠ nobody" chip rather than as an innocuous blank.
There is no such thing as "not configured, therefore open". If a permission does not name a role, it is denied to everyone, for every document of that type, until someone grants it. This is the single most important sentence in this topic: an earlier model left ungranted transitions silently open, and the day that changed, a project locked itself out of revising its own documents without any screen ever saying so.
A type with no stored policy at all is the same state written out: empty workflow groups, so new documents of it cannot be submitted, and no standing permission granted to anyone.
When a button is missing, read the box¶
This is the flip side of the same property, and it is worth knowing before you meet it: a half-configured policy locks people out of every transition nobody was granted, and it does so without complaining. Nothing is broken — the rows were simply never filled in — but the person who wanted to revise, revoke or cancel a document just finds the action absent, with no screen explaining why.
So when somebody reports "the button is missing", the first place to look is this box, on that document's type: the ⚠ nobody markers are the answer. A row marked nobody is exactly the action that person cannot perform. Grant it to the role they hold, save, and the action appears.
4. What is refused, and what only warns¶
Saving runs one check, and it has tiers.
Refused (the save does not happen). A prescribing type whose Revoke row is empty. The server says why, in words, naming the type and the standard:
'
' is a prescribing document type, so its 'Revoke' permission must grant at least one role: a released procedure that nobody can revoke cannot be withdrawn when it becomes obsolete (ISO 13485 §4.2.4). Grant it to the role that owns document control in this project — typically the Quality Manager — and save again.
Warned loudly, but saved. Each of these is occasionally intended, so the system says what you are choosing rather than deciding for you:
- Revoke empty on a record or template type — such a document can never be withdrawn from force. Intended only for a record series that is by design never revoked.
- Cancel empty on any type — nobody may cancel a draft or in-review version; only a version's own author can abandon it, so anyone else's abandoned draft stays in the list forever.
- Revise & periodic review empty on any type — no one may record a periodic review or start a revision, so a released document of this type can never be updated through the periodic-review loop.
- A grant to a role with no active holder — the permission exists but nobody can exercise it. Flagged inline, with the role named.
The same findings appear on the project's setup check chip afterwards, worded identically, so re-reading the configuration can never contradict what the save just told you.
5. The toggles beside the grants¶
Unlike the role lists, these apply live to every document of the type:
- Four-eyes review — a round's submitter can never be its approver. Enforced at approval time.
- Release mode — Explicit (a releaser releases) or Automatic (the last approval releases; still held back by unresolved comments or a missing questionnaire).
- Block release while review comments are unresolved — the comment quality gate.
- Release flow (records) — Standard or Direct (single-person release from draft), available only on record types. The box carries the house doctrine above it: before configuring direct release, ask whether the record — and the process step producing it — is needed at all. See the lifecycle chapter §4a.
6. Saving is honest¶
The box saves as a whole and tells you when it has unsaved changes. If a save fails, the box resets to the stored configuration and says so — "Not saved, and the box was reset to the stored configuration:" followed by the server's reason. A failed save never impersonates a successful one.
7. Where to start: the house four-eyes set¶
If you are configuring a type for the first time and have no reason to deviate, use the house four-eyes set. It is the grant set the setup wizard's lane presets write, so a project born through the wizard already has it:
| Row | Granted to |
|---|---|
| Authors (may submit) | Document Author, Quality Reviewer, Quality Manager |
| Reviewers (must approve) | Quality Reviewer — alone |
| Releasers (may release) | Quality Reviewer, Quality Manager |
| Revise & periodic review | Document Author, Quality Reviewer, Quality Manager |
| Revoke | Quality Manager |
| Cancel | Document Author, Quality Manager |
With four-eyes review on and release mode Explicit.
The shape behind it: anyone who may author may also hand their work in; approval is the one narrow gate, held by the quality function alone; document control — revoking a released document, cancelling somebody else's abandoned draft — sits with the Quality Manager; and everyone who works on documents may revise them, because revision is authoring, not authority. The author is in the Cancel row for their own convenience, not for control: a version's own author may always abandon it anyway.
Note that the Quality Manager is deliberately not in the approval row. Each role in Reviewers carries its own number of required approvals, so adding a second role there does not widen the pool — it adds a second mandatory signature. A Quality Manager listed as a reviewer would have to approve every document personally before it could be released. Keep the approval row as narrow as the review you actually want.
This is a starting point, not a rule. Every row is editable, before and after the wizard writes it; adjust it to the roles your project actually staffs, and re-read §4's warnings as you do.
Governing decisions: ADR-0096 (transition permissions — always visible, deny unless granted; the two sections; the tiered save validation), ADR-0064 (per-document workflow roles — the copy-then-independent template in section A), ADR-0091 (release modes — direct single-person record release), ADR-0054 (unstaffed-role detection — the inline "no active holder" warning), ADR-0073 (the scope-configuration surface). Regulatory frame: ISO 13485 §4.2.4 (control of documents — withdrawal of obsolete documents).