> For the complete documentation index, see [llms.txt](https://help.craftsmanplus.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.craftsmanplus.com/play/catalogue/publishing-states.md).

# Publishing States

Understand Preview, Draft, and Live catalogue publishing states, and how each affects share links and live creatives.

Publishing controls how and when catalogue changes become visible across all connected projects.\
Every catalogue has three distinct publishing states — **Preview**, **Draft**, and **Live** — each designed for a specific stage of review, testing, or public release.

This structure allows you to safely make updates, test them internally, and push them to production without disrupting live creatives.

| **State**   | **Purpose**                          | **Where Changes Appear**                                                                |
| ----------- | ------------------------------------ | --------------------------------------------------------------------------------------- |
| **Preview** | Local, immediate reflection of edits | Inside the **PLAY editor and preview mode only**                                        |
| **Draft**   | For internal or client testing       | Updates only the **share links** that already exist                                     |
| **Live**    | Public, production-ready data        | Updates **all exported and published creatives, even if they are already running/live** |

Each state represents a distinct version of the catalogue.\
Publishing to a higher state always overrides the previous version for all connected projects.

***

#### **Preview** <a href="#preview" id="preview"></a>

* Any edit you make in the Catalogue Editor appears instantly in the **Preview Mode** of a linked project.
* This allows you to test and validate changes from within the PLAY editor as you are building.
* Preview changes are **local only**, they don’t affect any external links or live creatives.

***

#### **Draft** <a href="#draft" id="draft"></a>

* Once changes are ready for review, click **Publish Draft** in the Catalogue Editor toolbar.
* Drafts update all internal and client-facing **Share Links** for connected projects.
* This is ideal for collaborative QA and approval rounds, enabling you to share updates to the catalogue without effecting any live projects.

<figure><img src="https://3019081569-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZBycFFNxrdS0X9OsGtmT%2Fuploads%2Fgit-blob-279281f72c54aec0377add51c06fda386b496b10%2Fimage-20251112-205949.png?alt=media" alt=""><figcaption></figcaption></figure>

***

#### **Live** <a href="#live" id="live"></a>

* When ready for public release, click **Publish Live** in the Catalogue Editor toolbar.
* All projects linked to that catalogue will automatically begin using the new data the next time they load.
* There’s no need to rebuild or re-export any projects, the update happens dynamically.
* Live publishing replaces the previous production version.

<figure><img src="https://3019081569-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZBycFFNxrdS0X9OsGtmT%2Fuploads%2Fgit-blob-60f48ea4eb00afd14a6e9bd1e8e264262c887023%2Fimage-20251112-210133.png?alt=media" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.craftsmanplus.com/play/catalogue/publishing-states.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.