Workflows

A workflow is the review process entries of a content type go through before they're published. You build one in the dashboard under Settings → Workflows: the stages an entry passes through (for example Draft → In review → Published), the moves allowed between them, and which roles can make each move.

How it works

• Every workflow has one start stage, where new entries begin, and one publish stage. Any number of review stages can sit in between.
• Each stage has reviewers: roles (such as Admin or one of your custom roles) and specific team members. They're the people who can make the moves out of that stage. Owners can always make every move, and a move into or out of the publish stage also needs the Publish and unpublish entries permission.
• A move goes from one stage to another. It can go forward, skip a stage, or go back (for example "Request changes" from In review to Draft). By default, the stage's reviewers can make it. Turn on Only specific people to limit a move to its own roles and people instead, for example so only an editor-in-chief can publish.
• A move can ask for a note. The note is kept with the entry's stage history and sent to the people who are notified.
• Moving an entry into the publish stage publishes it. Moving it out of the publish stage unpublishes it.
• When an entry reaches a stage, that stage's reviewers are notified, in the app and by email (owners only when the stage names nobody). The entry's author is also notified when it's sent back to the start stage.
• The entry's stage button shows who it's waiting on, and the entries table's status filter has Waiting on me: the entries at a review stage where you're a reviewer.
• A content type can be in one workflow. Types without a workflow publish directly, as before.

Workflows are part of the team's plan. A plan without them can't create workflows, and workflows that already exist stop applying.

Comments

Entries and content types have a comments drawer, opened from the speech-bubble button next to the info button in their header, with the number of comments beside it. Anyone on the team who can see content can read and add comments; ⌘ Enter sends.

A note added to a workflow move is saved as a comment too, marked with the move (for example In review → Draft), so the whole conversation is in one place. The entry's author and everyone who has commented are notified of new comments. You can delete your own comments; owners and admins can delete anyone's. Workflow notes can't be deleted.

Publishing is through the workflow

For a content type with a workflow, entries can't be published or unpublished any other way: not from the status menu, not with bulk actions, not by import, and not over GraphQL. Those requests return an error that names the workflow. Saving an entry's content, and moving it between draft and archived, work as usual.

The stage field

Every entry returned by the REST API has a stage: the workflow stage the entry is at, or null when its content type has no workflow (or the entry is archived).

{
  "id": "z0q8w1e2r3t4",
  "title": "Release notes for October",
  "slug": "release-notes-october",
  "status": "draft",
  "stage": { "id": "st_4k2m9x0s", "name": "In review" },
  "language": "en-US"
}

In GraphQL, ContentEntry.stage is a WorkflowStage with id and name:

1query {
2  contentEntries(contentType: "blog-posts", status: "draft") {
3    entries {
4      title
5      stage { id name }
6    }
7  }
8}

An entry that hasn't moved yet is at the start stage, or at the publish stage if it was already published before the workflow was set up. Stage ids stay the same when a stage is renamed.