Specific approvers for that step.
Reviews and approvals
Reviews and approvals
Dashboard → Reviews is the queue. It holds content submitted for approval because a policy or a workflow requires it.
Acting on it needs blueprint.review.
What an approver sees
The content as readers would see it, plus what changed since the last published version. On a first publish there is no previous version, so all of it is the change.
Decisions
| Decision | Effect |
|---|---|
| Approve | Publishes, or advances to the next workflow step |
| Reject | Returns to the author with your comment, to edit and resubmit |
Multi-step workflows
A workflow is an ordered list of steps, and a run sits on exactly one of them at a time. Approving advances it; the run is only finished when the last step approves.
Each step names its approvers two ways, and either is enough:
Named peopleuser ids
Rolesrole ids
Anyone holding one of these roles. Survives people joining and leaving, so prefer it over naming individuals.
Only the current step's approvers can act. Being an approver on step three does not let you approve step one.
A workflow accepts runs only when it is active and has at least one step. An active workflow with no steps takes nothing. If authors report that submitting does nothing, check the step list first.
Change requests are different
A change request is a proposal from someone without edit rights. A review is a gate on someone who has them. An author can withdraw their own change request, where only an approver can resolve a review.
Documentation has its own version of this: a folium with
requirePublishApproval files a change request instead of publishing when a
non-admin publishes a version, and the
REST API answers
202 Accepted rather than an error.