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.

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, as long as nobody has published the flag since you saved it.
• A stash of yours saved before a newer publish is never adopted on its own, because it would quietly undo that newer change. A banner offers it instead, so you can adopt it knowingly or discard it.
• A rule you are still typing into the side panel is not in your draft until you publish or save it. If you click a link that would leave the page with such changes, A vs B asks first: save them to your draft and leave, leave without them, or stay.

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 and rolls back to the last published snapshot. It clears your saved server draft too, so the reverted edits do not come back when you reload.
• Changes made outside the dashboard, for example through the API, wait for a publish too. The bar says so, Publish sends them, and Revert stays off because there is nothing in your tab to undo.
• Publishing to an environment that is paused, or has never been started, still updates what SDKs download. The flag stays switched off there until you click Run, and then it serves exactly what you published.
• If the update cannot reach SDKs, the publish is refused and nothing changes, so a success message always means SDKs have the change. Try again a moment later.
• Archiving, unarchiving, and deleting a flag reach SDKs straight away too: an archived or deleted flag disappears from every environment at once.

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.

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 changes, the review that opens (see below) checks the draft for changes to currently-running rules.

• If one or more Running rules are modified, deleted, or reordered, the review names them above the list of edits and warns that publishing changes behavior for live visitors immediately. The button reads Publish anyway.
• If the draft only touches Draft, Ready, Paused, or Concluded rules, there is no warning and the button reads Publish changes.
• Click Cancel to back out.

Reviewing changes before publish

Clicking Publish changes always opens a confirmation modal listing every staged edit, including a first rule on a new flag. A rule still open in the side panel is added to your draft first, so the list includes it. 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, and the only message you see afterwards is the publish's own result.

• Added or deleted rules render as a single row with a green or red left border and the rule's targeting + rollout summary inline.
• Edited rules render 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 and moved a rule, that single rule's update row picks up an "(also moved 2 positions up)" annotation.
• Environment settings and allowlist edits read as plain-language lines, with the default variation by name, for example Default variation: Low value → Answer.

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

Changing the environment clears the pending draft

A pending draft is saved against one exact published version of the environment. Anything that rewrites that version leaves the pending draft describing something that no longer exists, so A vs B saves it into History and clears it in the same step. These are the actions that do it:

• Starting the environment, or pausing it.
• Changing its settings, including the on/off toggle and the fallback variation.
• Setting or cancelling a schedule on it.
• A scheduled change firing, or being recorded as missed because it was too old to catch up.
• The same actions performed through the API with a token, not just from the dashboard.

Nothing is thrown away:

• The saved entry appears in the flag's History list with a line saying which action cleared it, for example Pending draft saved to history when the environment was started.
• Open that entry and restore it to bring the draft back, exactly like restoring any other version.
• If you were the one who acted, a message tells you the draft was saved to History.
• Anything you are still typing in your own open tab stays on screen. Auto-save simply re-saves it against the new version a few seconds later.
• An action that changes nothing (starting an environment that is already running) leaves the pending draft alone, because nothing was rewritten.

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.

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 History in 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.