> For the complete documentation index, see [llms.txt](https://docs.struct.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.struct.com/fundamental-concepts/drafts.md). # Drafts Drafts let you prepare changes to products, variant groups and variants without touching the current data, and merge them when they have been reviewed. This document describes how drafts let you work on changes in parallel with the current data, and how a change goes from a draft to the current data through review. ### Overview Product data often changes in rounds: a campaign rewrite, a season update, a new translation. The changes should not be visible to your channels before they are ready, and someone may want to look at them first. Drafts give you tools to: * Prepare changes to a product, variant group or variant without changing its current data * Keep several independent sets of changes on the same product * Send changes to a colleague for review, together with related drafts on the same product * Accept, reject or ask for changes field by field * Spot when the current data has changed since the draft was written *** ### Core concepts *** #### Drafts A draft is a named set of proposed changes to one product, variant group or variant. It can change attribute values and categories. Nothing in a draft reaches the current data until it is merged. A product can have several drafts at the same time, for example "Autumn campaign copy" and "Christmas gift guide". Each draft is independent of the others. Anyone who can see a product can see its drafts. Creating and editing drafts requires the **Edit drafts** permission. *** #### Status A draft moves through these statuses: * **Draft**: the author is still working on it * **In review**: the changes have been sent for review * **Changes requested**: a reviewer has sent one or more changes back with a note A draft can be edited at any time. Changes made after the draft was sent for review are kept apart until they are sent as well. *** #### Review and merge A reviewer decides each change in a draft: * **Accept** writes the value to the current data * **Reject** removes the change from the draft without writing it * **Request changes** sends the change back to the author with a note Changes the reviewer does not decide stay in the draft for later. When every change in a draft has been accepted or rejected, the draft is deleted. The merge is recorded in the [changelog](/tutorials/guides/how-to-use-the-changelog.md). Deciding the outcome of a draft requires the **Decide the outcome of drafts** permission and permission to edit the product, variant group or variant concerned. *** #### Conflicts A conflict means the current data changed in the same field after the draft was written. The reviewer chooses whether to keep the current value or take the draft's value, so nobody's work is overwritten without someone looking at it. *** #### Where drafts come from Drafts are written by users in the editor, by suppliers in the [Data Onboarding Portal](/fundamental-concepts/supplier-data-onboarding.md), by AI agents and by connected systems. They are all reviewed the same way. *** ### How it fits together * A user creates a draft on a product, variant group or variant and edits it like the current data * The user sends the draft for review, optionally together with related drafts on the same product * A reviewer finds the draft in the **Open drafts** dashboard widget and decides each change * Accepted changes are written to the current data, and the draft disappears when nothing is left in it *** ### Why it matters Drafts enable you to: * Prepare changes ahead of time without publishing them by accident * Add a review step where it matters, without slowing down everyday editing * Keep a clear record of who proposed a change and who accepted it * Use one review process for your own team, your suppliers and your integrations *** ### Related concepts * [Data Management](/fundamental-concepts/data-management.md) * [Workflows & Automation](/fundamental-concepts/workflows-and-automation.md) * [Supplier data onboarding](/fundamental-concepts/supplier-data-onboarding.md) * [Glossary](/glossary/overview.md) *** --- # 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://docs.struct.com/fundamental-concepts/drafts.md?ask=&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.