Drafts, publishing and versions

Editing a widget never changes what shoppers see. Every configuration change goes into a draft, and the draft only reaches your storefront when you Publish it.

That is two buttons, and they do different things:

• Save draft stores your work. Nothing on your storefront changes. You can leave and come back to it.
• Publish replaces the live version with your draft. The button carries the draft's number, so it reads Publish v3. The previous live version becomes Archived: it is kept, not deleted.

Publish is unavailable while you have unsaved changes. Publishing sends what is saved, so allowing it here would publish your previous draft while your unsaved change sat on the screen. Save first, then publish.

One draft per widget, shared by your organizationCopy Anchor Link

A widget has one draft, not one per person. Two colleagues editing the same widget are editing the same draft, and the later save is the one that survives. The draft reports who last touched it and when, so an overwrite is visible after the fact, and the widget list carries a Draft waiting marker so the work is visible before someone opens it.

What is versioned, and what isn'tCopy Anchor Link

Almost everything is: format, colours, size, corners, shadow, icon, placement, offsets, stacking order, page targeting, and the shopper-facing text.

Two things are not, on purpose:

• Active: the switch is how you take a widget off your storefront now. A merchant who switches a widget off expects it off, not off-once-published.
• Name: the label that tells two widgets apart in a list.

Both apply the moment you change them, and neither can be carried by a draft.

The Versions tabCopy Anchor Link

It lists every version with its status (Draft, Live, Archived, or, while an A/B test is running, Under test for the draft that got promoted into the test's candidate), the date it was published or last edited, and who did it. A version created by the migration that introduced versioning says so rather than being attributed to a person.

Restore on an archived version copies it back into your draft. It never publishes: a restored configuration is yours to review, preview and change before anyone sees it. Restoring while a draft already exists replaces that draft's contents.

Restore also keeps inherited fields inherited. An archived version whose background colour was never overridden comes back unset, not filled in with today's brand colour. Otherwise a restore would silently freeze the current colour into the widget and break it at your next rebrand.

Changing a widget's formatCopy Anchor Link

A widget's format used to be fixed at creation. It is now editable, at the top of the Design tab, through the same draft path as every other setting, so switching a chat bubble to a question bar changes nothing your shoppers see until you publish.

The two formats do not carry the same settings, so changing format drops what the new one has no place for: a chat bubble's side offset, position and icon; a question bar's placeholder. The editor names exactly which ones, with their current values, before it changes anything, and it says so only when something would actually be lost.

Your translated text carries across in both directions: a chat bubble's Text becomes a question bar's Placeholder, and back.

Restore makes the same disclosure. Restoring a version whose format differs from the one you are looking at names the fields it will drop, in the same words, before it commits, because "put back the one that worked" is the path you reach for by accident, so it is the one that most needs to say what it will cost.