How to create a content approval workflow
How to create a content approval workflow: scope each reviewer, run reviews in parallel, consolidate comments into one list and set a refresh date. Live example.
A content approval workflow takes a piece from brief to published page without three reviewers rewriting each other. Mapping it well means deciding who may say no and about what, which reviews run together, and what happens after publishing.
The short version
- Give every reviewer a written scope: what they decide and what they leave alone.
- Run independent reviews in parallel and make dependent ones follow, in the chart and in practice.
- Draw conditional reviews, such as legal, as a decision rather than a mandatory stop.
- Consolidate all comments into one list before the writer revises.
- Give the final decision explicit Rework and Rejected exits.
- Set a refresh date at publication and chart what happens when it arrives.
Who may say no, and about what
Most content approval problems are not about the writing. They come from reviewers who all see the whole draft and all comment on everything, so a brand editor rewrites the claims, a lawyer rewrites the tone, and the writer receives three conflicting versions. A chart helps because it forces you to state what each reviewer is there to decide.
Four decisions shape the workflow. First, scope: each reviewer gets a written remit, and the chart shows legal review as a conditional branch rather than a stop everyone passes through. Second, parallel or sequential: reviews that do not depend on each other can run at the same time, while a review that needs the output of another must follow it. Third, one consolidated change list, so the writer works from a single resolved set of comments. Fourth, what happens after publishing, because content that is never revisited goes stale.
The example below is a general content piece moving from request to publication and its scheduled refresh. Your reviewers, thresholds and timings will differ, and any regulated claims should go through your own legal or compliance procedure. Treat the chart as a structure to adapt, and compare it with the more general /guides/how-to-create-an-approval-workflow, or start from /templates/document-approval-workflow if your content is a controlled document.
A content piece from brief to refresh date
One piece of content from request to publication and its scheduled review. Notice the scoped reviews that fan out and the single comment list that pulls them back together.
A brief the draft can be checked against
The process starts when a content request is accepted onto the calendar, and the first real step is a brief: audience, goal, keyword and the claims to be made. The writer drafts against that brief with sources attached, and the first decision asks "Does the draft meet the brief?" A No sends it back to the draft before any reviewer sees it. Checking against a written brief is what stops later reviewers arguing about what the piece was meant to be.
Scoped reviews in parallel, one comment list
"Send to reviewers with a written scope for each" fans out to brand and voice, SEO and metadata, and a subject-matter accuracy check at the same time. Only the accuracy branch asks "Does it make claims that need legal review?" so legal sees a piece only when a claim calls for it. All branches then meet at "Consolidate comments into one list and resolve conflicts", and "Are changes required?" decides between revising and moving on.
The approval decision and its three exits
"Is the piece approved for release?" has three labelled exits rather than two: Approved, Rework and Rejected. Rework goes back to the revise step, where each comment is marked resolved, and the piece returns to the scoped review. Rejected leads to an exception step that parks or retires the piece and logs the reason, so a no is a recorded outcome instead of a file that goes quiet.
Publishing, the refresh date and who does what
Approved pieces are scheduled in the CMS with a publish date and owner, then published with a refresh date set. A delay step waits for that date, and "Is it still accurate and performing?" offers Keep, Update or Retire. Update drafts a new version and re-enters at the brief check; Retire redirects or archives the page. The lane columns put each step with the owner, writer, editor, specialist reviewers or publisher, so every handoff is visible.
How it works
List the reviews and the question each one answers
Write down every review the piece can receive and the single question it answers: is it on brand, is it accurate, is it findable, is it safe to say. If two reviews answer the same question, one of them is probably redundant. Put each reviewer type in its own swimlane in QueryChart.
Decide which reviews are always needed
Mark which reviews apply to every piece and which depend on content. Draw conditional reviews as a decision such as "Does it make claims that need legal review?" with labelled branches, so a routine piece does not queue behind a specialist it does not need.
Choose parallel or sequential
If reviews do not depend on each other, connect one step to several reviews and let them rejoin at a single step. If one review needs another's output, such as legal needing the accuracy check first, draw it in sequence. Fan-outs are easy to see in the Line to column, where one row points at several rows.
Consolidate comments before revision
Add a step after the reviews where one person merges comments into a single list and resolves conflicts between reviewers. Name the owner in a lane. Without it, the writer is the referee between reviewers.
Draw the approval decision with three exits
After consolidation, add the final decision with approved, rework and rejected branches. Point rework back at the revise step and rejected to a step that records the reason. Label each branch in Line text.
Add publication and a refresh date
After approval, chart scheduling, publishing and setting a refresh date. Add a wait step for that date and a decision to keep, update or retire. Agree the interval with the content owner; the number of days is yours to set.
Mistakes to avoid
Everyone reviews everything
Reviewers with no scope comment on whatever they notice, and their comments conflict. Give each review a written remit and show it in the step label.
Serial reviews that could run together
A chain of reviews that do not depend on each other adds waiting for nothing. Draw them as parallel branches and let them rejoin.
Comments returned one reviewer at a time
If each reviewer sends comments straight to the writer, conflicts surface late. Add a consolidation step so the writer receives one list.
No exit for a piece that is not going to be approved
A chart with only an approve-or-rework choice implies every piece eventually ships. Add a rejected exit that records why.
Publishing as the end of the process
Content that has no refresh date is never reviewed again. Chart the wait and the keep, update or retire decision.
Map your own content approval workflow
Open the content approval example as your own chart, rename the lanes to your reviewers, and set the refresh interval your team agrees.
Frequently asked questions
What is a content approval workflow?
The defined route a piece of content takes from request to publication: who drafts it, who reviews it, who decides it can go live and what happens afterwards. Drawing it as a chart makes the reviewers, their scope and the loops back to the writer visible.
Should content reviews run in parallel or in sequence?
Run them in parallel when they answer independent questions, such as brand voice and SEO, and in sequence when one depends on another's output. This guide does not set a rule for your organisation; the chart should show whichever you actually do so the waiting can be seen.
When does a piece need legal review?
That depends on the claims it makes and on your jurisdiction and industry, so check with your own legal or compliance team. The example models it as a decision after the accuracy check, so only pieces with claims that need it are routed to legal.
How often should published content be reviewed?
There is no universal interval. Pick one based on how quickly the subject changes and how important the page is, record it as the refresh date, and chart the decision to keep, update or retire. All day counts in the template are placeholders.
Where can I start from a template?
Open /templates/content-approval-process, or see /templates/document-approval-workflow for controlled documents and /guides/how-to-create-an-approval-workflow for the general approval pattern.