Publishing

Nothing an experience does reaches shoppers until you publish it. Building happens in a workspace; versions are how work leaves it, and publishing is how one version becomes the live one.

​

Versions

A version is an immutable snapshot of the experience as it was built at that moment. Saving one never overwrites an earlier version — it adds v2, v3, v4, each recorded with who saved it and when. That gives you three things the workspace alone can’t:

• A stable thing to share. A version renders the same for everyone, whether or not the workspace is awake.
• A safety net. Every earlier version stays available and publishable.
• A record. Who saved what, and which version went live when.

Saving requires the workspace to be running — a version is a snapshot of the current build, so there has to be a build to snapshot.

​

Saving

Two buttons, one difference. To publish a version you saved earlier — or roll back to an older one — pick it in the version picker and choose Publish. The picker marks the version that’s currently live.

​

The version picker

The picker above the canvas controls what you’re looking at: Switching between versions swaps the fragment on the canvas in place — the shop page around it doesn’t reload.

​

Rolling back

Rollback is publishing an older version. Pick it, publish it, and the live pointer moves — the experience isn’t rebuilt, re-validated, or re-rendered, so there’s no chance of the rollback producing something different from what that version originally was. This also means rollback is instant, and reversible in exactly the same way: publish the newer version again to move back.

​

Unpublished changes

An experience card shows Unpublished changes when its latest saved version isn’t the live one. That’s the normal state while work is in progress — it’s a reminder, not a problem. When the live version is the newest one, the card shows Live · v{n} instead.

​

Where a published version goes live

Publishing marks a version as the live one for that experience. What happens next depends on how the experience is bound.

​

When the Shopware sync fails

Pushing to Shopware is best-effort on purpose: a Shopware outage must not block a publish. If the slot update fails, the version still goes live in Frontic and you get told exactly that — the toast reads “v3 is live, but updating the Shopware slot failed”, and the experience card flags that the live version isn’t synced to the slot. Publish again once Shopware is reachable, and the slot catches up.

​

Sharing a preview

The share button copies a link to whatever you’re currently looking at — the live preview, or a specific version if one is pinned in the picker. Anyone on your team can open it. A shared version link is pinned, so a colleague opening it sees that exact version even if you keep building afterwards. That makes it the right thing to send for a sign-off.

​

Who can publish

Saving a version and publishing one are separate permissions. A teammate can be allowed to build and save versions without being allowed to make one live, which keeps the “who decides what shoppers see” question with the people who should own it. See Members and roles for how roles are assigned.

​

Publishing is not a release

Experiences sit outside Release Control. Publishing one doesn’t create a release, doesn’t wait for a release, and isn’t promoted from develop to public — it goes live when you press the button. That’s deliberate: the reason a campaign page can ship on a Tuesday afternoon is that it isn’t coupled to your backend’s release cadence. The flip side is that an experience isn’t rolled back by rolling back a release — roll it back by publishing an earlier version of the experience itself. Backend changes an experience depends on — a new Detail Block or Search Listing feeding it data — do still flow through releases in the normal way.

​

Related