---
url: /en/docs/workflows/preview.md
description: >-
  Preview changes in Sveltia CMS on a deploy preview before publishing them,
  without a review process.
---

# Preview Workflow

This is a remote workflow for editors who want to see their changes on a deploy preview before they go live, without a formal review process. It sits between the [Simple Workflow](/en/docs/workflows/simple), where a save goes live right away, and the [Editorial Workflow](/en/docs/workflows/editorial), where a change moves through review stages before it can be published.

Saving an entry commits it to a branch of its own and opens a pull request, just like Editorial Workflow. Hosting services such as [Netlify](https://docs.netlify.com/deploy/deploy-types/deploy-previews/), [Vercel](https://vercel.com/docs/deployments/environments#preview-environment-pre-production) and [Cloudflare Pages](https://developers.cloudflare.com/pages/configuration/preview-deployments/) build each pull request into a deploy preview, which the CMS [links to](/en/docs/workflows/deploy-previews) from the entry. Once you’re happy with the result, publish the entry to merge its pull request. There are no statuses to move it through.

## Use Cases

* Individual bloggers or small teams who want to check a change on a real build before it goes live.
* Sites whose pages are hard to judge from the editor’s preview pane alone, such as ones with complex layouts or data pulled from elsewhere.
* Teams that want to save work in progress without publishing it, but have no one to review it.

## Requirements

The requirements are the same as for [Editorial Workflow](/en/docs/workflows/editorial#requirements): the [GitHub](/en/docs/backends/github), [GitLab](/en/docs/backends/gitlab) or [Gitea/Forgejo](/en/docs/backends/gitea-forgejo) backend, and a sign-in that covers pull requests. A hosting service that builds deploy previews from pull requests is what makes the workflow worthwhile, though the CMS doesn’t require one.

## Configuration

Set the top-level `publish_mode` option to `preview`:

::: code-group

```yaml [YAML]
publish_mode: preview
```

```toml [TOML]
publish_mode = "preview"
```

```json [JSON]
{
  "publish_mode": "preview"
}
```

```js [JavaScript]
{
  publish_mode: 'preview',
}
```

:::

Like the other publish modes, `preview` can also be set on a collection, overriding the top-level setting. See [Enabling the Workflow per Collection](/en/docs/workflows/editorial#enabling-the-workflow-per-collection).

The object form of the option takes the [`direct_publish`](/en/docs/workflows/editorial#direct-publishing) and [`allow_incomplete_drafts`](/en/docs/workflows/editorial#required-fields) options too. For example, to let editors skip the preview for a quick fix:

::: code-group

```yaml [YAML]
publish_mode:
  type: preview
  direct_publish: true
```

```toml [TOML]
[publish_mode]
type = "preview"
direct_publish = true
```

```json [JSON]
{
  "publish_mode": {
    "type": "preview",
    "direct_publish": true
  }
}
```

```js [JavaScript]
{
  publish_mode: {
    type: 'preview',
    direct_publish: true,
  },
}
```

:::

## How It Works

Preview Workflow is Editorial Workflow with a single stage, Draft, so everything described under [How It Works](/en/docs/workflows/editorial#how-it-works) for Editorial Workflow applies, including the checks made before publishing. The differences are:

* An entry can be published as soon as it’s saved, with the Publish Entry button in the entry editor or on the Drafts page.
* The entry editor shows a Draft badge rather than a status menu, and the CMS doesn’t ask to send a saved entry for review.
* The Editorial Workflow page is called **Drafts**, and lays the unpublished entries out in a single column. If another collection uses Editorial Workflow with more than one stage, the page is a board with a column for each stage again, and an Open Authoring contributor always gets the board.
* Every pull request counts as a draft, whatever its label says. One labeled In Review or Ready by Editorial Workflow, by [Decap CMS](/en/docs/migration/netlify-decap-cms) or by hand can be published straight away, and its label is left alone.

Pull requests are labeled `sveltia-cms/draft` and kept as [draft pull requests](/en/docs/workflows/editorial#statuses), which the Git service won’t merge. Publishing an entry therefore marks its pull request ready first, relabeling it `sveltia-cms/pending_publish`, and then merges it. If the merge fails, the entry stays unpublished with the new label.

Switching between Preview Workflow and Editorial Workflow keeps every unpublished entry. Deleting a published entry opens a pull request that removes it, as with [Editorial Workflow](/en/docs/workflows/editorial#deleting-entries).

### Required Fields

A draft can be saved with its [required fields](/en/docs/fields#required) left empty, but they have to be filled in before the entry is published. See [Required Fields](/en/docs/workflows/editorial#required-fields) for details, including how to turn this off.

## Open Authoring

[Open Authoring](/en/docs/workflows/open) works with Preview Workflow as well. A contributor working on a fork still sends their entry for review when it’s ready, as they can’t publish it themselves. A maintainer then sees it as a draft that can be published right away.