How publishing works

Every piece of content in ROK sits in exactly one of three states: draft, in review, or published. Everything else you see in the console — scheduling, sign-off, review reminders — decorates that spine rather than adding states to it.

The three states

Draft is the working state. Anyone with Edit content can change a draft freely, and operators cannot see it. New content starts here, and content sent back for changes returns here.

In review means an author has handed the item over. It appears in the review queue, where it can be assigned to a specific person, given a due date and a priority. Reviewers either approve it or request changes; requesting changes moves it back to draft and leaves a comment explaining why.

Published means operators can read it. On their next sync the item lands on their device and stays readable offline.

The rules are in the database, not the buttons

This is the part worth internalising: hiding a button is not what stops content going live.

A trigger on the content table checks the permission for every state change as it happens — publishing needs Publish, submitting for review needs Submit for review, withdrawing needs Unpublish. The console hides controls you can't use so the screen stays honest, but the check that matters runs in Postgres.

Scheduling doesn't add a state

A scheduled item is still a draft or in-review item with a publish time attached. Setting that time is publishing in advance, so it needs Publish, and the database records who set it. When the time arrives, a background job publishes the item as it stands — but only while the person who scheduled it still holds Publish, and only with the two-person sign-off approvals its current version needs, counting the scheduler as the publisher. An item that fails either check is skipped and stays queued until it passes. Scheduling cannot get round a permission or an approval.

You can see everything waiting on a clock in the scheduled queue (opens the admin console), and reschedule or cancel from there.

Sign-off sits in front of published

Some content shouldn't go live on one person's say-so. When an item requires two-person sign-off — either because someone flagged that item, or because a policy matches its type, a tag, or the guide it lives in — publishing is refused until enough other people have approved the current version.

Two details catch people out:

• Approvals are pinned to a version. Any saved change bumps the version — the words, but also a status change or a new cover — and quietly invalidates approvals already given. A publish time does not: scheduling or rescheduling an approved item keeps its approvals.
• Once such an item is published, edits to it are held rather than refused: operators keep the approved version until the changes are approved and released. There is no silent republish.

Editing published content

A published item has two copies: the working copy the console edits, and the released copy operators receive. A save reaches operators at their next sync only when the person saving holds Publish and the item needs no sign-off. Any other change is held: an author with Edit content alone, or anyone editing an item that needs sign-off, changes the working copy and nothing else. Someone with Publish then sends the changes out with Release to operators, after any approvals the item needs. The review queue (opens the admin console) lists everything waiting to be released.

After publishing

Publishing isn't the end of the item's life:

• Operators receive the item at their next sync. A scheduled publish also sends them a push, deep-linked to the item; after a manual publish, send one with Notify operators if they need to know now.
• The item starts ageing against your review interval, and reappears in review due (opens the admin console) when it's stale.
• Operators can flag an issue from the app, which lands in field reports (opens the admin console) for triage.