Content lifecycle: draft, review, publish

TL;DR

• Every entry moves through workflow stages (Draft, Review, Approved, Published) that control who can act on it next.
• Publishing is a separate action from workflow transitions, an "Approved" entry is not automatically live.
• Publish rules tie workflow stages to environments, protecting production from unapproved content.

Content does not appear on a website the moment someone types it into a CMS. Between creation and delivery, every piece of content passes through a series of states that determine its visibility, its readiness, and who is allowed to act on it next. Contentstack formalizes this progression through a workflow engine that tracks where each entry sits in its lifecycle and controls how it moves forward.

The stages of the content lifecycle

Every entry in Contentstack moves through a predictable lifecycle: creation, editing, review, approval, publishing, and (optionally) unpublishing. Contentstack implements this through configurable workflow stages, role-based permissions, and explicit publishing actions, giving you precise control over each transition.

Contentstack's default workflow stages

Every new stack ships with a default workflow containing four stages:

flowchart LR
    Draft -->|Editor submits| Review
    Review -->|Reviewer approves| Approved
    Review -->|Reviewer rejects| Draft
    Approved -->|Publish action| Published
    Published -->|Unpublish| Approved
    Published -->|Edit| Draft

New entries start in Draft. When ready, the editor transitions them to Review. A reviewer either sends the entry back to Draft (with feedback) or advances it to Approved. From Approved, someone with publishing permissions publishes to one or more environments. The "Published" stage is set automatically by the system when the publish action completes, you do not move entries to it manually.

How the workflow engine works

The workflow engine operates on a few core principles:

• Entries exist in exactly one workflow stage at any time. The current stage is a single, definitive state.
• Transitions can be manual or automatic. With Automation Hub, transitions can be triggered based on events or conditions.
• Stages can have permission restrictions. For example, only "Editors" might move entries from Draft to Review, and only "Managing Editors" from Review to Approved.
• The workflow stage is visible throughout the UI. Colored labels in the entry list let teams filter by stage, essential for managing a review queue.

Publishing is separate from workflow stages

Common pitfall:

An entry in the "Approved" stage is not automatically published. Publishing and workflow status are independent dimensions, always check both when debugging content visibility.

The publish action is not a workflow transition. An entry can be Approved yet published to zero environments, or published to staging while still in Review (if publish rules allow it).

The publish action works like this: select entries, choose target environment(s) and locale(s), optionally schedule, and confirm. The entry enters the publish queue and is processed asynchronously.

If an article is in the "Approved" workflow stage but has not been published to production, the delivery API query will not return it. The workflow stage and the published state are completely independent dimensions.

Unpublishing: removing content without deleting it

Unpublishing removes an entry from a specific environment's delivery API without deleting the entry from Contentstack. The entry remains in the CMS with all its content, history, and metadata intact. It simply stops being delivered to the specified environment.

This is useful in several scenarios:

• Seasonal content: a holiday promotion needs to be removed from production after the holiday, but kept in the CMS for next year.
• Corrections: an article with factual errors needs to be pulled from the live site while it is corrected, then republished.
• Environment-specific visibility: content might be unpublished from production but remain published to staging for QA testing.

Unpublishing is environment-specific. Unpublishing an entry from production does not affect its presence in staging or development. Each environment maintains its own independent publish state.

The relationship between workflow stages and environments

Workflow stages and environments interact through publish rules, which you configure to enforce governance. The most common pattern ties the ability to publish to specific environments to the entry's current workflow stage:

This configuration means that an entry in the Draft stage cannot be published to any environment. An entry in Review can be published to development and staging (for QA verification), but not to production. Only entries that have reached the Approved stage can be published to production.

This pattern gives teams a way to preview content in non-production environments during the review process while protecting the production environment from unapproved content. The workflow stages act as gates, and the publish rules act as the locks on those gates.

Configuring this relationship is covered in detail in the next lesson on designing workflows.

Bulk workflow operations

When a team manages hundreds of entries, moving them one at a time through workflow stages is not practical. Contentstack supports bulk workflow operations:

• Bulk stage transition: select multiple entries from the entry list and move them all to a different workflow stage in a single action.
• Bulk publish: select multiple entries and publish them to one or more environments simultaneously.
• Bulk unpublish: remove multiple entries from an environment at once.

These bulk operations respect the same permission rules as individual operations. If a user does not have permission to move entries to the "Approved" stage, a bulk transition to "Approved" will fail for those entries while succeeding for others where the user has the necessary permission. Bulk operations are accessible from the entry list view by selecting multiple entries using the checkboxes and choosing the desired action from the toolbar.

Example: content lifecycle at a news organization

Consider a digital news organization that publishes 40 articles per day. Their workflow mirrors a traditional newsroom:

Reporters create articles. They fill in the headline, body text, hero image, category tags, and author reference. The article starts in the Draft stage. A reporter might save the article multiple times as they write, add quotes, and attach images.

Section editors review articles. A reporter moves the completed article to the Review stage. The section editor for that category (Sports, Politics, Business) reads the article, checks facts, verifies image credits, and either sends it back to Draft with comments or advances it to Approved.

The managing editor makes the final call. Articles in the Approved stage are reviewed by the managing editor during the daily editorial meeting. The managing editor may reorder publication priority, adjust headlines, or hold articles for a later date.

The publishing desk executes the publish. An operations team member publishes approved articles to the production environment. They may also schedule articles for timed release - an interview set to go live at 6 AM, or an earnings report timed to market close.

In this setup, the workflow stages map directly to newsroom roles:

Each role has clear responsibilities, and the workflow engine enforces those boundaries. A reporter cannot publish directly to production, and the publishing desk cannot bypass the editorial review process.

Viewing workflow state across the stack

Contentstack provides several views for monitoring workflow state:

• Entry list filtering: filter entries by workflow stage to see all content currently in "Review," for example.
• Workflow stage column: the entry list displays the current workflow stage for each entry as a visual indicator.
• Audit log: every workflow transition is recorded in the audit log, showing who moved which entry to which stage and when.
• Dashboard widgets: Contentstack's dashboard can surface workflow-related metrics.

For teams managing high volumes of content, the ability to filter by workflow stage and sort by last-modified date is essential for identifying bottlenecks. If 30 articles are stuck in "Review" and only 2 are in "Approved," the review team is the bottleneck.

Common mistakes

Mistake 1: Confusing workflow stage with publish state

An entry in the "Approved" stage is not published. An entry that is published is not necessarily in the "Published" workflow stage (it might still show "Approved" if the workflow does not include a post-publish stage update). These are two separate systems. Workflow tracks editorial readiness. Publishing controls delivery availability. Always check both dimensions when troubleshooting why content is or is not appearing on your site.

Mistake 2: Skipping the review stage for "small changes"

A common justification for bypassing workflow is "it's just a typo fix." Typo fixes are how broken links, deleted paragraphs, and accidental field clears reach production. The workflow exists to catch mistakes, and mistakes do not scale with the perceived size of the change. Keep the workflow intact for all content changes, or explicitly carve out a fast-track workflow for minor edits with its own review step.

Mistake 3: Publishing to production from the wrong workflow stage

Without publish rules configured, any user with publish permissions can publish any entry to any environment regardless of its workflow stage. This defeats the purpose of having a workflow at all. Always configure publish rules to restrict which stages can publish to which environments, as described in the next lesson.