> ## Documentation Index > Fetch the complete documentation index at: https://docs.frontic.com/llms.txt > Use this file to discover all available pages before exploring further. # 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. > [card] Save version > > Saves the current build as a new version. **Nothing goes live** - > use it to bank a good state before trying something risky, or to > hand a version to a colleague for review. > [card] Save & publish > > Saves the current build as a new version **and** makes it the live > one. Experiences in a project share some code - components, translation helpers, design tokens. When the agent changed shared code while building this experience, saving asks first and lists it. That shared code is saved with the version, and the other experiences in the project pick it up from there - see [Working alongside other experiences](https://docs.frontic.com/designer/building.md#working-alongside-other-experiences). 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: | Entry | Shows | | - | - | | **Live preview** | The current build in the running workspace - what the agent is working on right now | | **v1, v2, v3…** | A saved version, rendered exactly as it was saved | | **Public** | Jumps to whichever version is currently live | 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 shoppers get that version exactly as it was saved. Its code comes back too: the workspace returns to that version's code, so you keep building from what's live, and unsaved changes to the experience are replaced. Versions saved before versions kept their code are the exception - publishing one moves what's live, and the workspace code stays as it is. Rollback is reversible in the same way: publish the newer version again to move back. ### Restoring a version's code To go back to the live version's code without publishing anything, open the version menu and pick **Restore v*N*'s code**, where *N* is the live version. Your workspace goes back to that version's code, and any unsaved changes in it are replaced - which is why it asks first. A restore doesn't create a version and doesn't change which one is live. It's for abandoning a line of work, not for changing the storefront. ## 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. > [tab] Bound to Shopware > > Publishing writes the version's rendered content into the Shopware CMS slot the experience was created from. The next storefront request renders it - no cache warm-up, no deploy, no Shopware plugin update. Shoppers see it in the storefront's current language; if the version wasn't built in that language, they see its primary language instead. > > The success toast links straight to both sides: **Open Layout** goes to the Shopping Experience layout in your Shopware admin, **Open Storefront** goes to the live page. > > See [Frontic Experiences in Shopware](https://docs.frontic.com/connectors/shopware.md#frontic-experiences-in-shopware) for the full round trip. > [tab] Not bound > > Publishing moves the live pointer inside Frontic, and the published version becomes the one everyone sees when they open the experience or its share link. > > Delivery into a storefront that isn't Shopware isn't generally available yet. Experiences you build this way are fully usable for design, review, and sign-off today; talk to [support](mailto:support@frontic.com) if you want to place one on a non-Shopware storefront. ### 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 a saved version - the one on screen, or the latest save when you're watching the live preview. Anyone with the link can open it - your team, or a client you build for - which makes it the thing to send for a sign-off. Links expire after a while, so send a fresh one if a sign-off drags on. A link is always pinned to a saved version, so the recipient sees exactly that version even if you keep building. If nothing has been saved yet, Share asks you to save a version first. A link that no longer works opens a page that says why - expired, turned off, or not a valid link - and asks the visitor to get a new one from you. ### Stepping through versions A shared preview with multiple versions shows a **Versions** control in its toolbar. Visitors can step through them in place, one at a time from the first to the latest, or press play to travel through them automatically - a quick way to show your team how a page got where it is. ## Who can publish Only an experience's [owner](https://docs.frontic.com/designer/building.md#ownership-and-read-only-viewing) can publish it. Everyone else on the team can open it, share it and follow along, but making a version live is the owner's call. The same applies to restoring a version's code, since it replaces the owner's workspace. ## Publishing is not a release Experiences sit outside [Release Control](https://docs.frontic.com/releases/overview.md). Publishing one doesn't release an API version and doesn't wait for one - the experience is published 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 tied to an API version - [roll it back](#rolling-back) by publishing an earlier version of the experience itself. Backend changes an experience depends on - a new [Detail Block](https://docs.frontic.com/api-builder/blocks.md) or [Search Listing](https://docs.frontic.com/api-builder/listings.md) feeding it data - still reach your customers by [previewing and publishing a version](https://docs.frontic.com/releases/release-flow.md). ## Related > [card] [Building an experience](https://docs.frontic.com/designer/building.md) > > The canvas, stages, and Designer settings. > [card] [Shopware connector](https://docs.frontic.com/connectors/shopware.md) > > Creating experiences from Shopware and publishing back into a > CMS slot. > [card] [Experience Designer](https://docs.frontic.com/designer/overview.md) > > What experiences are and how to create one. > [card] [Release Control](https://docs.frontic.com/releases/overview.md) > > How backend changes ship - a separate flow from experience > publishing. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.