> ## 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. 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. Saves the current build as a new version **and** makes it the live one. 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 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. 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. 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](/connectors/shopware#frontic-experiences-in-shopware) for the full round trip. 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 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. Preview links are team-scoped — the recipient needs a Frontic account on your team. Guest links for people outside the team aren't available for experiences yet. ## 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](/admin/members-and-roles) for how roles are assigned. ## Publishing is not a release Experiences sit outside [Release Control](/releases/overview). 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](#rolling-back) by publishing an earlier version of the experience itself. Backend changes an experience depends on — a new [Detail Block](/api-builder/blocks) or [Search Listing](/api-builder/listings) feeding it data — do still flow through releases in the normal way. ## Related The canvas, stages, and Designer settings. Creating experiences from Shopware and publishing back into a CMS slot. What experiences are and how to create one. How backend changes ship — a separate flow from experience publishing.