Strapi Content Lifecycle — Draft/Publish, Versioning, and Workflows

In this tutorial, you will learn how Strapi manages content throughout its lifecycle — from draft creation through review, publishing, and future updates — using the draft/publish system, versioning, and workflow features.

What You'll Learn

• How the draft/publish workflow works and when to use it
• How to configure content types with or without draft/publish
• Scheduled publishing basics (Strapi 5)
• Review workflows for multi-step approval processes
• How content lifecycle status affects API responses
• Content localization lifecycle with i18n

Why It Matters

Content is rarely ready to publish the moment it is created. Writers draft content, editors review it, managers approve it, and publishers schedule it. Strapi's content lifecycle features mirror this real-world Process. Understanding how to configure and use these features keeps your content organized, prevents accidentally publishing incomplete work, and supports editorial teams with structured workflows.

Real-World Use

A news website has writers who create article drafts, editors who review and request changes, and a managing editor who schedules publication. With Strapi's draft/publish system, writers work in drafts without fear of publishing prematurely. Editors see only articles assigned to them. The managing editor schedules articles to publish at optimal times. The API automatically serves only published content to visitors.

Learning Path

flowchart LR
  A["Content Types"] --> B["Fields"]
  B --> C["Relations"]
  C --> D["Components"]
  D --> E["Content Lifecycle
-- You are here"]:::current
  E --> F["REST API"]

  classDef current fill:#4945ff,color:#fff,stroke-width:2px

Draft/Publish Basics

Every Strapi content type includes a draftAndPublish option. When enabled, each entry has two states: draft and published.

• Draft: The entry is visible in the admin panel but excluded from public API responses. Editors can modify drafts freely.
• Published: The entry is visible in the public API. Editors can still modify published entries, but the changes remain in draft until explicitly published.

// Content type schema configuration
// src/api/article/content-types/article/schema.json
{
  "kind": "collectionType",
  "options": {
    "draftAndPublish": true  // Enable draft/publish (default: true)
  }
}

When draftAndPublish is true, Strapi adds a publishedAt and publishedBy field to the entry. Published entries have a publishedAt timestamp. Draft entries have publishedAt: null.

// API response for a published entry
{
  "data": {
    "id": 1,
    "attributes": {
      "title": "Published Article",
      "publishedAt": "2026-06-28T10:00:00.000Z"
    }
  }
}

// Draft entries are excluded from public API responses
// GET /api/articles returns only entries with publishedAt != null

How the Admin Panel Handles Draft/Publish

In the Content Manager, each entry shows its status with a badge:

• Draft: Gray badge. Entry needs publishing.
• Published: Green badge. Entry is live in the API.
• Modified: The published version remains unchanged. A "Publish changes" button appears.

Editors can:

1. Create a new entry as draft
2. Edit the draft
3. Publish the entry (becomes visible in the API)
4. Unpublish an entry (removes from the API)
5. Edit a published entry and publish the changes

You might be wondering what happens to the published version when an editor edits without publishing. The published version remains live in the API. The edits are saved as a new draft state. This means there is no automatic "save and publish" — editors must explicitly publish their changes.

Disabling Draft/Publish

Some content types do not need draft/publish. For example, a "Category" type might always be published because there is no reason to draft a category.

// Disable draft/publish
{
  "options": {
    "draftAndPublish": false
  }
}

When disabled, every entry is automatically published. The publishedAt field is set immediately upon creation. There is no publish button in the admin panel.

Disable draft/publish for:

• Reference data (categories, tags, types)
• System settings
• Configuration content
• Data that must always be available

Content Versioning

Strapi 5 introduced a content versioning system. Each time an entry is updated, Strapi can save a version history. This lets you:

• View previous versions of an entry
• Compare versions side by side
• Restore an older version

Versioning is configured per content type in the schema options:

{
  "options": {
    "draftAndPublish": true,
    "versioning": true  // Enable version history
  }
}

Versioning adds storage overhead because each edit creates a new version record. For content types with frequent edits and large fields (richtext, JSON), the version history can grow quickly. Consider enabling versioning only for content types that genuinely need it.

Review Workflows

Strapi 5 added native review workflows (previously available only through enterprise plugins). Review workflows define stages that content passes through before publication.

A typical workflow might be:

Draft -> In Review -> Approved -> Scheduled -> Published

Each stage can have different approvers. An editor submits content for review. A senior editor approves it. A manager schedules the publication date. The content publishes automatically.

Review workflows are configured in Settings > Review Workflows. You define the stages, the order, and which user roles can transition content between stages.

// Workflow stages
[
  { "name": "Draft", "color": "gray" },
  { "name": "In Review", "color": "blue" },
  { "name": "Approved", "color": "green" },
  { "name": "Scheduled", "color": "orange" },
  { "name": "Published", "color": "emerald" }
]

Scheduled Publishing

Scheduled publishing lets you set a future date and time for content to publish automatically.

In the Content Manager entry editor, there is a "Schedule publication" option. Editors can set a datetime in the future. Strapi automatically publishes the entry at that time.

// Scheduled publish configuration
// Strapi runs a cron job that checks for scheduled entries
// and publishes them when their scheduled time arrives

// The scheduled time is stored in Strapi's internal scheduling system
// and processed asynchronously

Scheduled publishing requires the Strapi server to be running at the scheduled time. If the server is down, the publication is delayed until the server restarts and the scheduler catches up.

Content Lifecycle and the API

The content lifecycle directly affects API responses:

// Only published entries appear in public API
GET /api/articles
// Returns only entries with publishedAt != null

// Draft entries return 404 for public users
GET /api/articles/2  // (draft entry)
// Response: { "data": null, "error": { "status": 404 } }

// Authenticated requests with proper permissions can see drafts
GET /api/articles/2
// With JWT token of admin user
// Response: { "data": { ... }, "meta": {} }

The API also supports filtering by publication state:

// Get only published entries (default)
GET /api/articles?publicationState=live

// Get only draft entries (requires auth)
GET /api/articles?publicationState=preview

// Get all entries (requires auth)
GET /api/articles?publicationState=all

Content Localization and Lifecycle

When using the i18n plugin, each locale has its own lifecycle. An article can be:

• Published in English
• Draft in French (translation not ready)
• Published in Spanish

Each locale's publication status is independent. The API returns content based on the requested locale and that locale's publication state.

Common Mistakes

1. Publishing unfinished content. Without draft/publish, saving an entry immediately makes it live. Enable draft/publish on content types where incomplete content should not be visible.

2. Forgetting to publish after editing. Editors edit published entries but do not click the publish button. Their changes never appear in the API. Always check for entries with "Modified" status.

3. Disabling draft/publish when you need it. Once draft/publish is disabled, you cannot enable it without affecting existing entries. Plan your content types carefully.

4. Not configuring review workflows for team environments. Without workflows, any editor can publish any content. Use review workflows when multiple people are involved in content creation.

5. Ignoring version history limits. Version history grows with every edit. Configure retention policies to prevent storage bloat. Set a maximum number of versions per entry.

Practice Questions

1. What is the difference between a draft entry and a published entry in Strapi? Answer: Draft entries are visible in the admin panel but excluded from public API responses. Published entries are visible in the public API. Draft entries have publishedAt: null, published entries have a timestamp.

2. How does the API filter content based on publication state? Answer: By default, the API returns only published entries. You can use ?publicationState=preview to see drafts or ?publicationState=all to see both. Preview and all require authentication.

3. What happens to a published entry when an editor saves changes but does not publish? Answer: The published version remains live in the API unchanged. The edits are saved as a draft state, shown with a "Modified" badge in the admin panel. The changes appear only after the editor explicitly publishes.

4. Challenge: Set up a complete editorial workflow for a blog: (1) Create a content type "Post" with draft/publish enabled, (2) Create three admin users with roles of Writer, Editor, and Publisher, (3) Configure a review workflow with Draft, In Review, Approved, and Published stages, (4) Demonstrate the full lifecycle by having the Writer create a draft, the Editor review and approve, and the Publisher publish.

FAQ

Mini Project

Your task: Create and manage a content lifecycle workflow.

1. Create a "Press Release" collection type with fields: title (string, required), body (richtext, required), author (string), department (enumeration: marketing, pr, executive).
2. Configure draft/publish on this type.
3. Create 3 press releases: one as draft, one as published, and one as draft with scheduled publication for tomorrow.
4. Create a review workflow with stages: Draft, Legal Review, Manager Approval, Scheduled, Published.
5. Test the API: verify that only published entries appear in the public API, that drafts return 404, and that authenticated requests with proper permissions can see all entries.

What's Next

Now that you understand the content lifecycle, proceed to REST API to learn how to consume your content programmatically through CRUD endpoints, filtering, sorting, and pagination. After that, explore API Parameters for advanced querying.

Related lessons:

• REST API — API consumed by frontend
• GraphQL — Alternative API approach
• Node.js — How Strapi manages Background Jobs