Saving and Publishing Drafts

The flag detail page edits a single document — your draft — and the bottom bar exposes one explicit action: Publish changes. Everything you type, toggle, or reorder is auto-stashed to the server in the background; only an explicit publish promotes the stash to a live snapshot.

Save & Publish persists the body of a rule — its targeting, audiences, variations, traffic split, name, schedule. Turning a rule or environment on or off goes through the dedicated Run and Pause controls and is sent live immediately, bypassing the draft. See Rule Statuses for that flow. The bottom bar never flips a rule live.

Auto-save

While you edit a flag's rules, default variation, scheduling, or overrides, every change is held locally in your draft. About five seconds after you stop typing, the draft is silently stashed on the server. The SDK and snippet keep serving the previous published snapshot — the stash is invisible to end users.

The bottom bar's status indicator reads Auto-saved 12s ago after the most recent stash, or Saving… while a stash is in flight.
If a teammate publishes a change while you have unsaved edits, the conflict banner appears and the indicator switches to Auto-save paused — resolve conflict first. Auto-save resumes once the conflict is resolved.
Refreshing the page or opening the flag in a second tab adopts your last-saved stash so no work is lost.

Auto-save only requires createExperiments permission — even on the production environment. Only the explicit Publish action checkspublishProduction. This lets editors stage changes anywhere without the ability to ship them.

Publishing changes

When you click Publish changes, the staged draft is committed to the live tables, the prior server stash is cleared, and the new snapshot starts serving through the SDK and snippet immediately.

The button is disabled when there are no staged changes, while a save is in flight, or while a remote conflict is unresolved.
Revert next to Publish discards every staged edit in this session and rolls back to the last published snapshot.

Why are new rules drafts?

Newly-created rules land in your draft in Draft status — never run, with their toggle off. Auto-saving and publishing both leave the new rule in Draft. The only path to making a rule live is the dedicated Run button, which opens its own confirmation modal and writes through to the SDK datafile immediately. The brand-new rule card pulses briefly to signal that the rule is staged but not live.

This prevents the “I clicked save and the rule went live to end users without a review step” surprise. It also gives reviewers a chance to inspect the rule (in the change review panel, in audit logs, or via a teammate's eyes) before it serves any traffic.

Copying or duplicating a rule always produces a Draft regardless of the source's state. Even if the source was Running, the new copy is a Draft until you click Run on it. See Rule Statuses for the full lifecycle.

Publishing changes that affect running rules

Editing a Running rule is allowed and goes into the draft like any other change. When you click Publish, A vs B checks the draft for changes to currently-running rules.

If the draft only touches Draft, Paused, or Concluded rules, the publish proceeds without a prompt.
If one or more Running rules are modified, deleted, or reordered, a confirmation modal appears listing the affected rules and warning that publishing will change behavior for live visitors immediately.
Click Cancel to back out, or Publish anyway to commit.

Reordering a Running rule counts as a publish-affecting change, because the rule's position determines which rule wins for a visitor that matches more than one.

Reviewing changes before publish

Clicking Publish changesopens a confirmation modal listing every staged edit. Each row gets the right level of detail for what changed — high-level for additions, deletions, and ordering changes; rich diffs for edits in place. There is no separate “Review changes” button — the diff is part of the publish flow.

Added or deleted rulesrender as a single row with a green or red left border and the rule's targeting + rollout summary inline.
Edited rulesrender a per-rule mini diff with chip lists for added/removed audiences and metrics, before/after bar charts for variation weights, and a number diff for traffic allocation. A “See full variation diff” link expands a side-by-side variation table when you need every key, weight, and value visible.
Reordering rules without editing anything else collapses into a single “Reordered N rules” entry with a tooltip showing the new order. If you both edited andmoved a rule, that single rule's update row picks up an “(also moved 2 positions up)” annotation.
Env-config and env-level override editsstay as plain-language lines; there's no rich diff for them today.

You can publish from inside the modal or close it and continue editing.

Multi-author stashes

Each flag environment holds at most one server-side draft at a time. If two editors save drafts back-to-back, the later auto-save replaces the earlier one. The next viewer always sees the most recent stash.

If you need real-time conflict signaling for parallel edits, the SSE-based snapshot channel surfaces a banner the moment a teammate publishes — auto-save pauses and the conflict resolution UI takes over.

Restoring a previous published version

Every publish is captured in a per-flag history log. You can roll back any flag environment to a previously-published version, or promote a snapshot from one environment to another.

Open Historyin the flag's left sidebar — under Flag Setup, alongside Variations and Settings — to browse every publish across every environment, filter the list, and restore a snapshot to any active environment. See History & Restore for the full walkthrough.