Review queue

The review queue lists every item that is in review: an author has submitted it and it is waiting for someone to check it. Open it from the sidebar under Workflow → Review queue. This is where you decide who reviews what, by when and how urgently. A second card below it, Changes awaiting release, lists published items whose saved changes operators do not have yet.

You do not publish from this page. Open an item (select its title) to read it and publish it from the editor. The queue is also not the place for published content that has gone stale — that is Review due (opens the admin console), a different clock.

Who can do what

The priority, due date and reviewer controls are editable only for people who hold Edit content; everyone else sees them as plain text. Apart from Approve, every action on this page changes the item itself, which the database allows only for people who hold Edit content — the buttons are guidance, not the lock.

The toolbar

A line above the table reads "Sorted by priority, then due date. New assignments default to N days", where N is your agency's review deadline from Settings → Review policy (opens the admin console) (14 days until someone changes it).

Only mine narrows the table to items where you are the reviewer. Select it again to see everything.

How the queue is ordered

The most pressing item is always at the top:

1. Priority — Urgent, then High, then Normal, then Low.
2. Due date — within a priority, the soonest deadline first. Items with no due date sit below every dated item of the same priority.
3. Time waiting — remaining ties put the item that has gone longest without a change first.

Columns

Assigning a reviewer

Pick a person from the Reviewer list on the row. You can hand a review to anyone — the list is every active member of your agency, sorted by name, with (you) after your own name. It is deliberately not filtered to people who hold review permissions: what the assignee can actually do with the item is decided by the database when they try. Assign someone who holds the permissions the job needs.

What happens when you assign someone:

• They become the reviewer, and the item records who assigned it and when.
• If the item has no due date yet, it gets one: your agency's review deadline, counted in days from now. If its priority is still Normal, it also takes your agency's default priority.
• The new reviewer gets a notification in the bell: "“…” was assigned to you for review", followed by the due date when there is one. Selecting it opens the item. Review assignments are also emailed by default (each reviewer can change that in their email preferences); assigning several at once sends one email, not one each. Nobody is notified when you assign a review to yourself.

Choose Unassigned to take the review away from someone. That clears the due date as well.

Two shortcuts on the right of the row do the same for you:

• Claim appears on unassigned items and assigns the review to you, with the same due-date and priority defaults.
• Release appears on items assigned to you and unassigns you, clearing the due date.

Priority and due date

Change Priority at any time. As a guide: Urgent is operational risk that should be reviewed before anything else, High goes ahead of routine work, Normal is routine editorial review, and Low is whenever there is time. Priority decides the order of the queue; it does not affect the content or who can act on it.

Due is a date picker. The deadline is the end of the day you pick, so "due Friday" means by the close of Friday. Clear the field to remove the deadline. Each change saves as soon as you make it.

Two-person sign-off

The Sign-off column shows the requirement the database will enforce at publish: the Required box on the item's own Two-person sign-off card, and every approval policy that matches its content type, a tag, or a guide it sits in. Where several apply, the largest number counts.

• Needs approval, or x of N approvals when more than one is needed — the item's current version has fewer approvals from people other than the author than it needs.
• Approved — it has them.
• — — nothing requires sign-off.

The item's Two-person sign-off card in the editor names the policies that apply.

Approve appears on every row that requires sign-off — even one marked Approved, since an approval from whoever then publishes does not count — for people who hold Second approval, when you are not the item's author and have not already approved its current version. Selecting it records your approval against the version as it stands now. What happens next:

• The approval counts only for that version. Editing the item or changing its status afterwards moves it to a new version, and the approval stops counting. Assigning, re-prioritising, changing the due date on this page, or setting or moving its publish time does not.
• The database refuses an approval from the item's own author, and from anyone without Second approval.
• Approving does not publish. At publish time, only approvals from people other than the author and the publisher count — so if yours is the only approval, someone else has to publish. See how two-person sign-off works.

Request changes

Request changes sends an item back to its author. A dialog opens with an optional note — "What needs to change? (optional)" — and two buttons, Cancel and Send back to author.

When you select Send back to author:

• If you wrote a note, it is posted as a comment on the item. The author, and anyone already commenting on it, get a "New comment on …" notification.
• The item returns to Draft and leaves this queue. Its due date is cleared, and so is any scheduled publish time, so it cannot go live on the old schedule.
• The author gets a notification in the bell that the item "was returned to draft for changes", whether or not you wrote a note. If you are the author, that notification is not sent.
• Because the item changes state, it moves to a new version. Approvals given before it was sent back no longer count once it is resubmitted.

Changes awaiting release

The second card lists published items with saved changes that operators do not have yet. Changes to a published item are held when the person saving does not hold Publish, and always when the item needs two-person sign-off; operators keep the version last published or released until someone releases the changes. See "Editing a published item" in The content editor.

The most recently changed item is at the top.

There are no actions on this card. Open the item and use Review changes on its Changes since last publish card to see what changed. If it needs sign-off, approve it there as usual; then someone who holds Publish selects Release to operators. The approvals count is version-qualified like everything else: saving another change starts it again. At the release, an approval from the person releasing does not count, so if the count only reaches the requirement with yours, someone else has to release.

When nothing is held, the card reads "Operators have the latest version of everything published."

When the page is empty or fails

• Loading… shows while the queue loads.
• Nothing awaiting review. means no item in your agency is in review. With Only mine on, the message is Nothing assigned to you.
• If the queue cannot be loaded, the error message appears in place of the table.

Live updates

The queue refreshes itself whenever an item in your agency changes — a new submission appears, and an assignment made in another window shows up, within a moment. Changes awaiting release does the same. This depends on Live updates being switched on in Settings → Features (opens the admin console). With it off, the queue refreshes when you open the page or act on a row; reload to see other people's changes.