--- 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/websites/headless-cms/approval-workflows/ tags: - websites - 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-11-02T03:00:00.000Z" language: en-AU publisher: National Digital author: Tara Buckley authorRole: COO reviewedBy: Cameron Young reviewedOn: "2026-11-02" readingTimeMinutes: 8 wordCount: 1548 datePublished: "2025-10-01" dateModified: "2026-11-02" pillar: websites canonical: https://nationaldigital.com.au/websites/headless-cms/approval-workflows/ sourceCount: 2 --- *8 min read · Updated 2 November 2026* # 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. National Digital [designs, builds, hosts and supports](/about/) the platforms it delivers, with no reseller or integrator between the client and its engineers. **Where this page sits** · 1 of 22 areas Areas this page covers - Content & CMS [Open the full map on the homepage](/#systems-map-hero) **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? *High confidence · Verified 20 Oct 2026* 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](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. *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](/websites/digital-experience-platforms/digital-experience-platform-companies/), 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](/websites/headless-cms/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](/websites/headless-cms/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**: 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**: 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 launch** *Critical* — 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 uniformly** *Important* — 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 work** *Helpful* — 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 lack** *Important* — 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. - **Pre-publish review gate: Mandatory checkpoint** — 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** — 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** — 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](/websites/headless-cms/approval-workflows/) 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 Send us your content types and get workflow states, role permissions and audit trails scoped to the actual risk of each one. - [Book a workflow review](https://calendly.com/cameron-at-national-digital/discovery) - [Email our team](mailto:enquiries@nationaldigital.com.au) or · [1300 800 855](tel:+611300800855) ## 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. Written by [Tara Buckley](/about/tara-buckley/), COO Reviewed by [Cameron Young](/about/cameron-young/), CEO, on 2 November 2026 ## Related reading - [Content workflow automation](/websites/headless-cms/content-workflow-automation/) - [Headless WordPress setup](/websites/headless-cms/headless-wordpress-setup/) - [Version control for headless CMS content](/websites/headless-cms/version-control/) - [User permissions in a headless CMS](/websites/headless-cms/user-permissions/) - [What Contentful Developers Actually Build During a Migration](/websites/headless-cms/contentful-development/) - [Storyblok Development: What's Actually Included, and When It Beats Contentful](/websites/headless-cms/storyblok-development/) ## Related **Parent:** - [Headless CMS migration consultants and development Australia](/okf/websites/headless-cms.md) # Citations 1. [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. 2. [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.