Draft, publish, version
A recipe always exists in two parallel forms: the draft you are editing, and the published version that is actively serving customer conversations.
From the recipes list you can tell at a glance which form is in which state — the Status column shows a coloured pill (drafting, published, or archived), the Version column shows the live version number for published recipes, and the action column on the right surfaces only the actions valid for that status.

The draft
- Every change you make on the canvas writes to the draft.
- Drafts autosave on a 60-second debounce after the last edit, and immediately when you switch tabs or close the browser tab (so nothing is lost on accidental navigation away).
- You can also force an immediate save with the Save button in the canvas header bar.
- The autosave uses an ETag-based concurrency control: if another author edited the same recipe in parallel, the next save raises a conflict resolution prompt.
- The draft is invisible to customers — only the published version runs.
The canvas header bar shows the current mode (Edit Mode / View Mode / Read-only), the last-saved timestamp, and any outstanding validation issues:
![]()
Publishing
Publish lives in the editor’s outer header, alongside the Version History button:

To publish:
- Resolve every blocker (red dots in node headers).
- Click Publish in the editor header.
- The Publish modal lists every blocker and warning the validator found. Blockers must be fixed before you can confirm. Warnings can be acknowledged and shipped.
- Optionally add a change note (visible later in the version history), then confirm to create a new published version.

If only warnings remain, the confirm button reads Acknowledge & Publish. If blockers are present, the confirm button is hidden until you fix them — open the canvas, address every blocker, then re-open the Publish modal.
If you are an admin and a Recipe Copilot is configured, clicking Publish with blockers also auto-opens the Craft Copilot panel to the Diagnose tab, so each issue has a one-click Fix it → button next to it.
In-flight sessions on the previous published version continue to completion against that older snapshot — sessions never silently jump to a new version mid-flow.
Versioning
Each publish creates a versioned snapshot. Open Version History from the editor header to see every published version of this recipe — newest at the top, each row showing the version number, publish timestamp, change note, and the author who published it.

From any row you can Rollback — re-publish that older snapshot as the active version. Rollback creates a new version entry (it doesn’t rewind the version counter), so the audit trail stays linear.
Conflict resolution
If two authors edit the same recipe in parallel, the second to save sees a conflict modal:
| Choice | Effect |
|---|---|
| Discard my changes | Server’s draft is loaded into your canvas; your local changes are dropped. |
| Overwrite their changes | Your draft replaces the server’s draft. Use only when you’re sure the other author’s work is obsolete. |
| Decide later | Modal closes; nothing is saved. You can copy your work elsewhere before retrying. |
To prevent conflicts entirely, coordinate edits via Slack/email or use the subflow pattern so different authors own different recipes.
Read-only mode
If you don’t have edit permission for a recipe (your role is readonly, or your team doesn’t own it), the canvas opens in read-only mode — you can view, navigate, simulate, but every mutation is disabled.