How it works
How two-person sign-off works
Why an item needs a second approval, when ROK refuses to let one person publish alone, why approvals expire when content changes, and how policies make the rule automatic.
Some procedures are dangerous enough that one person's judgement shouldn't be the only thing between a draft and an operator's hands. Two-person sign-off makes ROK refuse the publish until someone else has read it.
What the rule actually is
An item that requires sign-off cannot be published until enough distinct people have approved its current version. The people who approve must be someone other than both the author and whoever is doing the publishing — so a single person holding every permission still cannot push it through alone. The same rule applies to releasing changes to an item that is already published, and to a scheduled publish, where the person who set the schedule counts as the publisher.
Approving requires the Second approval permission, and the system refuses an approval from the item's own author.
Approvals are pinned to a version
This is the detail that surprises people. An approval records the exact version it approved. Any saved change bumps the version — an edit to the title, summary or body, but also a status change, or a new cover, hero image or colour — and every approval given against the old version stops counting. Setting or moving a publish time is not a change to the item: approvals survive it.
That is deliberate. An approval is a statement about specific words, not a general endorsement of the item. If the words change, the statement no longer applies.
Editing gated content that is already published
Once a gated item is live, you can still edit it — even its title, summary and body — but the changes are held. Operators keep the approved version while you prepare the next revision. To send the changes out, someone gives the approvals on the new version, and then a person who holds Publish selects Release to operators on the item. The release is refused until the approvals are there, from people other than the author and the person releasing. Nothing unreviewed reaches operators in between.
Making it automatic
Flagging items one at a time doesn't scale. Approval policies apply the rule by rule instead: match on content type, on a tag, or on a guide — and a guide policy covers its sub-guides too. Each policy sets how many approvals it needs.
A per-item flag and any matching policies fold together into a single required count, so turning on a policy never quietly weakens an item somebody had already flagged by hand.
Manage them under Settings → Approvals (opens the admin console).
Scheduling doesn't dodge it
A scheduled publish runs the identical check when its time arrives, with the person who set the schedule as the publisher: approving an item and then scheduling it yourself does not count as two people. If approvals have lapsed because someone edited the item in the meantime, the scheduled publish is held back, and the item waits in the queue rather than shipping unapproved content.
See also
- How it worksHow publishing worksThe path a piece of content takes from a blank draft to something an operator can read offline — and what the database will and won't let you skip.
- How toPublish a guideTake an approved guide live so it syncs to every operator's device and stays readable offline.
- ReferenceApproval policiesMake two-person sign-off automatic — require one to three approvers for every item of a content type, every item carrying a tag, or everything inside a guide.