<p>Strapi's Draft &amp; Publish feature separates a draft version from the live version. I add an editorial status because "saved as a draft" does not say whether a writer is working, a reviewer has approved it, or publication is scheduled.</p><p>The <a href="https://docs.strapi.io/cms/features/draft-and-publish">Strapi Draft &amp; Publish documentation</a> documents Draft, Modified, and Published states. I use those platform states for public visibility and a small editorial workflow for responsibility.</p>

<h2>Define editorial states</h2>

<p>My basic states are idea, drafting, ready for review, changes requested, approved, and archived. Only an approved record can move to publication. The state names identify the next owner rather than describing how complete the writer feels.</p><p>I keep this field distinct from Strapi's reserved publication status. In Strapi 5, a content type with Draft &amp; Publish cannot use <code>status</code> as a custom attribute, so I choose a name such as <code>contentStatus</code>.</p>

<h2>Require a reviewable record</h2>

<p>A reviewer needs the body, unique metadata, canonical target, internal links, source notes, and image plan. I block the handoff when required fields are blank. The writer includes questions or disputed claims in a review note instead of hiding them in the copy.</p><p>Relations also need review. Publishing an article linked to an unpublished category or author may omit expected API data.</p>

<h2>Protect previews</h2>

<p>A preview route fetches the draft with an authorized server request. It does not expose a public token in browser code. This site's local review route uses <code>noindex,nofollow,noarchive</code>, stays out of the sitemap, and is disabled in production. A deployed CMS preview should likewise require authenticated or signed access.</p><p>I test the preview as a reviewer and the public route as an anonymous visitor. Draft content should not leak through a broad public API permission.</p>

<h2>Record the reviewer decision</h2>

<p>The approval record names the reviewer, time, reviewed version, and any conditions. A later edit returns the content to review unless the team has defined fields that may change without another approval.</p><p>Strapi's Modified state shows that the draft differs from the published version. I use that signal to prevent an old approval from covering new copy.</p>

<h2>Publish and verify</h2>

<p>Publishing updates the public record, but the frontend may still cache the old response. I trigger the documented revalidation path, then fetch the article, category, sitemap, and structured data. The publication record stores the observed result.</p><p>If verification fails, I can unpublish or restore the prior content according to the rollback procedure. The editor sees the failure rather than a misleading success toast.</p>

<h2>Keep the queue visible</h2>

<p>A dashboard groups items by owner and state. I limit simultaneous drafts so review does not become a pile of stale work. Scheduled releases include timezone and cancellation checks.</p><ul><li>Editorial and publication states stay separate.</li><li>Previews require server-side authorization.</li><li>Approvals identify the reviewed version.</li><li>Publishing triggers live verification.</li><li>Failed releases remain visible.</li></ul>

<h2>Need help with Strapi?</h2>

<p>Terry Hunt Dev builds editorial controls and previews through <a href="/services/strapi-development">Strapi development services</a>. Use the <a href="/contact">contact page</a> to describe your current roles, review states, and publication failures.</p>

Create a practical Strapi draft and publish workflow with review states, metadata checks, protected previews, publication records, and rollback steps.

A Practical Draft and Review Workflow for Strapi

Separate writing status, review decisions, preview visibility, and public publication in a Strapi workflow.

Draft and Publish Resources & Benchmarks

A Practical Draft and Review Workflow for Strapi

Need hands-on help with Draft and Publish?