Approval workflows for headless CMS publishing
How approval workflows gate headless CMS publishing across channels, and where teams get it wrong. Talk to National Digital.
Quick answer: Approval workflows gate headless CMS content through draft, review and publish states so nothing reaches a website, app or feed until an authorised reviewer signs off.
- Headless CMS
- Content Workflow Automation
- Digital Governance
Quick answer
How do approval workflows work in a headless CMS?
Content moves through defined states: draft, review, approved, scheduled, with each transition gated by role-based permissions, so nothing reaches a website, app or kiosk until an authorised reviewer signs off.
Additional Context
Relevant for teams running a decoupled CMS where one piece of content can reach multiple channels simultaneously.
Sources
- Digital Service Standard
Australian Government guidance establishing baseline practices for publishing content to the public, including review before release.
- Privacy Management Framework
OAIC guidance on demonstrating accountability for decisions made about information handling, including documented approval trails.
Content governance
Why headless CMS publishing needs explicit approval workflows
A headless CMS separates content creation from the channels that display it, delivering stories, product data and pages through an API to a website, a mobile app and sometimes a partner feed at the same time. That reach is the appeal of a headless CMS platform, but it also means one careless publish can go live everywhere at once with no human checking it first. Traditional CMS platforms bundle editing and presentation together, so a mistake usually shows up on one website. A headless CMS without a workflow has no equivalent safety net.
How approval workflows actually work in a headless CMS
Most implementations define a small set of states for each content type: draft, in review, approved, scheduled and published. Moving between states is gated by role-based access control, so a contributor can submit content for review but only a designated approver can push it toward the live API. Pairing workflow states with content version history means a reviewer can compare what changed since the last approved version rather than re-reading an entire page.
Teams migrating from a monolithic CMS often add workflow as an afterthought once the new platform is already in production, only to discover that content types built without a status field require a schema migration to retrofit one, and existing live entries don't automatically inherit a default state. That gap is where unreviewed edits slip through in the first few months after launch.
Publishing risk
Approval Workflows for Headless CMS Publishing
Problem
Content can publish across multiple channels without a mandatory review step, creating compliance and brand risk because no single person signs off before it reaches customers.
Common Pain Points:
- Unreviewed content going live Draft or incomplete content reaches the website, app or partner feed before anyone has signed off on it.
- No record of who approved what When a problem appears post-publish, there's no audit trail showing which reviewer approved the change or when.
- One-size-fits-all review chains The same multi-step approval applies to every content type, slowing low-risk updates without improving control over high-risk ones.
Business Impact:
Time Wasted: Hours spent unpicking content published without sign-off
Cost Implication: Rework and compliance exposure from unreviewed publishes
Opportunity Cost: Marketing and compliance teams unable to trust what's live without manually checking it first
Solution
A staged workflow enforced inside the CMS: draft, review, approval and scheduled publish, with role-based gates so only authorised users can move content to live channels.
Our Approach:
- Map content types to risk and approval depth(Typically 1-2 weeks)
Classify each content type by how much review it genuinely needs, from single sign-off to multi-stage legal review.
- Build workflow states into the content model(Typically 2-4 weeks)
Add draft, review, approved and scheduled states as first-class fields, with transition rules tied to role permissions.
Expected Outcome: Content reaches live channels only after passing the approval stages defined for its type, with a full record of who approved what and when.
Key Takeaways
Governance and speed can coexist in headless publishing
- Workflow states need to exist in the content model before launchCritical
Retrofitting a status field onto content types with existing live entries forces a data migration and risks entries bypassing the new gate until edited.
- Approval depth should scale with content risk, not apply uniformlyImportant
A single heavyweight chain for every content type slows teams on low-risk updates while barely improving control over genuinely high-risk pages like pricing or legal copy.
- The front-end framework has no bearing on how approvals workHelpful
Whether content is rendered through React, Next.js or a native app, the CMS enforces draft, review and publish states before anything reaches the delivery API.
- Enterprise platforms like AEM bring workflow engines lighter CMSs lackImportant
Lightweight headless platforms often need webhooks or custom tooling to replicate the multi-step, audited approval chains that AEM provides natively.
Approval workflows protect multi-channel publishing from reaching customers unreviewed, but only when workflow states are designed into content types early and scaled to the actual risk of each content type.
Approval Workflow Benchmarks for Headless CMS
Baseline reference points for how Australian organisations structure governance and accountability around digital content before it reaches customers.
Mandatory checkpoint
Pre-publish review gate
Significance: highGovernment digital service guidance treats a review step before publication as a baseline control, not an optional extra, for content reaching the public.
Source: Digital Transformation Agency, Digital Service Standard
Documented decision trail
Accountability for published content
Significance: mediumPrivacy governance guidance expects organisations to show who approved content handling decisions and when, which an audit-logged workflow satisfies directly.
Source: OAIC, Privacy Management Framework
Author, approver, publisher
Role separation in publishing
Significance: mediumSeparating the person who drafts content from the person who authorises it to go live is a recurring control pattern across editorial and compliance workflows.
Methodology
Drawn from published Australian government digital service and privacy governance guidance applicable to organisations publishing content via API-driven platforms.
Implementation
Building approval workflows without slowing down publishing
The common failure mode is applying the same heavyweight chain to every content type. A blog post correction and a change to a product's regulated disclosure text do not carry the same risk, so they shouldn't share an approval depth. Editorial workflow automation that routes content to the right approver based on content type and field changes keeps low-risk updates moving while still gating anything that touches pricing, legal copy or compliance statements behind a second reviewer.
Choosing a headless CMS platform with workflow support
Platform choice matters here. Contentful and Sanity provide draft and published states with role permissions, but multi-stage approval chains generally need custom logic built on webhooks. Strapi needs a workflow plugin. An enterprise headless CMS such as AEM running in headless mode inherits Adobe's native workflow engine, which is why organisations with legal or regulatory sign-off requirements often accept the extra implementation effort it demands. None of this changes depending on the front end: a headless CMS feeding React or Next.js enforces the same approval states as one feeding a native app, because the front-end framework only renders whatever the CMS has already approved and marked for delivery. A business migrating off a legacy platform, as in the WordPress to headless CMS migration for a multi-site operator, typically finds workflow design easier to get right during the migration than retrofitted afterward.
Approval workflows in headless CMS publishing: common questions
Do headless CMS platforms include approval workflows out of the box?
Support varies widely. Contentful and Sanity offer draft and published states with role permissions but multi-stage approval chains typically need custom logic via webhooks or a workflow add-on. Strapi needs a plugin. AEM's headless CMS mode inherits Adobe's workflow engine, which is why heavily regulated enterprises often choose it despite the higher implementation cost and complexity.
Is AEM a headless CMS with built-in approval workflows?
Adobe Experience Manager can run headless, delivering content via GraphQL or Content Fragments while keeping its native workflow engine for multi-step approvals, audit trails and role-based gating. That workflow depth is the main reason enterprises with legal or compliance sign-off requirements choose AEM over lighter headless platforms, even though it demands more specialist implementation effort.
How is approval different in a headless CMS versus a traditional CMS?
In a traditional CMS, publishing and presentation are bundled, so approval usually gates one website. In a headless CMS, approved content is distributed via API to every channel at once, meaning a single approval decision can push content live on a website, app and partner feed simultaneously, which raises the stakes of getting the gate right.
Can approval workflows slow down content teams using a headless CMS?
They can if every content type runs through the same heavyweight chain regardless of risk. The better pattern scopes approval depth to content type and channel: low-risk product descriptions might need one editor sign-off, while pricing or legal pages require a two-step review before the API makes them available to the front end.
Does using React or Next.js affect how approval workflows are configured?
Approval logic sits entirely in the CMS layer. A headless CMS feeding a React or Next.js front end handles the same draft, review and publish states as one feeding a mobile app, because the front-end framework only renders whatever the CMS has already approved and marked for delivery.
What happens to live content when a new approval workflow is introduced?
Existing published entries don't automatically inherit workflow states, which is the step most teams underestimate. Adding a status field to a content type already populated with live content usually requires a migration to backfill a default state, otherwise older entries can bypass the new gate entirely until someone edits them.
