--- type: Leaf title: Approval workflows for headless CMS publishing description: How approval workflows gate headless CMS publishing across channels, and where teams get it wrong. Talk to National Digital. resource: https://nationaldigital.com.au/headless-cms/content-workflow-automation/approval-workflows/ tags: - headless-cms - Headless CMS - Content Workflow Automation - Digital Governance - headless cms approval workflow - headless cms publishing workflow - enterprise headless cms - aem headless cms - headless cms react - content governance headless cms - headless cms platforms timestamp: '2026-10-20T08:23:48.132Z' language: en-AU publisher: National Digital author: Cameron Young authorRole: CEO readingTimeMinutes: 7 wordCount: 1385 datePublished: '2025-10-01' dateModified: '2026-10-20' pillar: headless_cms canonical: https://nationaldigital.com.au/headless-cms/content-workflow-automation/approval-workflows/ --- _Home — Content & Experience — Content workflow automation — Approval workflows for headless CMS publishing_ # 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. ## About this page - Written by Cameron Young, CEO - 7 min read - Updated 20 October 2026 _Headless CMS — Content Workflow Automation — Digital Governance_ ## 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. _High confidence · Verified 20 Oct 2026_ *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](/headless-cms/content-workflow-automation/digital-experience-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](/headless-cms/content-workflow-automation/user-permissions), 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](/headless-cms/content-workflow-automation/version-control) 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** 1. **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. 2. **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 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. - **Workflow states need to exist in the content model before launch** Retrofitting a status field onto content types with existing live entries forces a data migration and risks entries bypassing the new gate until edited. _Critical_ - **Approval depth should scale with content risk, not apply uniformly** 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. _Important_ - **The front-end framework has no bearing on how approvals work** 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. _Helpful_ - **Enterprise platforms like AEM bring workflow engines lighter CMSs lack** Lightweight headless platforms often need webhooks or custom tooling to replicate the multi-step, audited approval chains that AEM provides natively. _Important_ ## Approval Workflow Benchmarks for Headless CMS Baseline reference points for how Australian organisations structure governance and accountability around digital content before it reaches customers. - **Pre-publish review gate: Mandatory checkpoint** _Significance: high_ — Government 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)_ - **Accountability for published content: Documented decision trail** _Significance: medium_ — Privacy 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)_ - **Role separation in publishing: Author, approver, publisher** _Significance: medium_ — Separating 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](/headless-cms/content-workflow-automation/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](/case-studies/nrma-parks-and-resorts/) for a multi-site operator, typically finds workflow design easier to get right during the migration than retrofitted afterward. ## Map an approval workflow for your headless CMS National Digital designs workflow states, role permissions and audit trails into headless CMS implementations, scoped to the actual risk of each content type. - [Book a workflow review](https://calendly.com/cameron-at-national-digital/discovery) - [Email our team](mailto:enquiries@nationaldigital.com.au) - Email: enquiries@nationaldigital.com.au - Phone: 1300 800 855 ## 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. ## Related reading - [Version control for headless CMS content](/headless-cms/content-workflow-automation/version-control/) - [User permissions in a headless CMS](/headless-cms/content-workflow-automation/user-permissions/) - [Editorial workflow automation in a headless CMS](/headless-cms/content-workflow-automation/editorial-workflow-automation/) - [Digital Experience Platform](/headless-cms/content-workflow-automation/digital-experience-platform/) - [Support automation and Australian English](/ai-automation/ai-agents/support-automation/) - [Ticket management automation and ACL obligations](/ai-automation/customer-service-automation/ticket-management/) ## Related **Parent:** - [Content workflow automation](/okf/headless-cms/content-workflow-automation.md) **Related:** - [Digital Experience Platform](/okf/headless-cms/content-workflow-automation/digital-experience-platform.md) # Citations - [Digital Service Standard](https://www.dta.gov.au/help-and-advice/digital-service-standard) — Australian Government guidance establishing baseline practices for publishing content to the public, including review before release. - [Privacy Management Framework](https://www.oaic.gov.au/privacy/guidance-and-advice/privacy-management-framework-enabling-compliance-and-encouraging-good-practice) — OAIC guidance on demonstrating accountability for decisions made about information handling, including documented approval trails.