Drafts

How drafts work, and how you disable them

In Sanity Studio, when you create a new document or edit one that has already been published, a draft document is created. Drafts capture in-flight updates while the original published document remains intact. This enables keeping changes separated from what is presented to users until those changes are ready to be explicitly rolled-out.

A draft document does not appear on the APIs to unauthenticated users. While you may refer to it as a reference, you can only publish a document that references a draft if that reference field is a weak reference.

When you publish a document it becomes available on the public APIs and you may (strongly) reference it from other documents.

When you start working on a published document a new draft gets created. This creates a new event in the document history. You can access the document history from the context menu:

Drafts are saved in a document with an id beginning with the path drafts.. When you publish a document it is copied from the draft into a document without the drafts.-prefix (e.g. drafts.ca307fc7-4413-42dc-8e38-2ee09ab6fb3d vs ca307fc7-4413-42dc-8e38-2ee09ab6fb3d). When you keep working a new draft is created and kept read protected in the drafts document until you publish again.

The published and draft document both have _createdAt and _updatedAt fields.

• _createdAt is the same value for both and reflects the time when the document was first created.
• _updatedAt on the draft is the time it was last edited.
• _updatedAt on the published document is the time it was last written to. Publishing writes to it, and so does any other mutation, including a patch sent straight to the published document by a script or the Mutations API.

_updatedAt moves whenever a document is written to, so it stops being a publish signal as soon as something writes outside the publish flow. A migration or maintenance script that patches published documents makes every one of them look freshly published.

If you need a publish date that only changes when someone publishes, model it as a field you control. Add a datetime field such as publishedAt to the schema, keep it out of your bulk scripts, and set it from a custom publish action. For an example, see Document actions.

Query it with coalesce() so documents that don't have publishedAt yet fall back to _updatedAt:

*[_type == "post"] | order(coalesce(publishedAt, _updatedAt) desc) [0...10] {
  title,
  "date": coalesce(publishedAt, _updatedAt)
}

[
  {
    "title": "Introducing content releases",
    "date": "2026-08-14T09:12:44Z"
  },
  {
    "title": "A note on migrations",
    "date": "2026-07-02T16:40:02Z"
  }
]

When querying your content from a frontend it's common to face a situation where you are interested in either drafted changes or published content, and specifically not both at the same time. You can use Content Lake's Perspectives feature to have your queries return with all in-flight changes applied – useful for previewing – or with all changes ignored entirely – useful for production deployments. Visit the article Presenting and Previewing Content to learn more about how Perspectives can be used in your presentation layers.

Sometimes you might not need drafts at all, such as when using real-time 'live' documents, or when using a structured publishing flow like Content Releases.

To disable all draft creation and limit editing to "live edit" documents, API mutations, and content releases, set the document.drafts.enabled setting to false in your sanity.config.ts file.

export default defineConfig({
  // ...
  document: {
    drafts: {
      enabled: false
    }
  }
})

To disable drafts for a data type that you want to be "live only", include liveEdit: true in the schema definition:

export default {
  name: 'author',
  title: 'Author',
  type: 'document',
  liveEdit: true,
  // ...rest of schema
}