Experience Builder project publishing
Publishing an Experience Builder project saves a versioned project snapshot and runs configured actions that release or deploy the project.
Publishing makes an Experience Builder project available for use outside the editor and enables published assets to be reused in other projects. Publishing consists of two stages:
- Save a published version of the project.
- Run any configured publish actions, such as deployment or release workflows.
This separation allows teams to create versioned project snapshots before deciding how and when changes are released.
Publishing workflow
Publishing consists of two stages:
- Save a published version of the project.
- Run any configured publish actions, such as deployment or release workflows.
This separation allows teams to create versioned project snapshots before deciding how and when changes are released.
Save a published version
When you publish a project, Experience Builder saves its current state as a new published version. Published versions are read-only and cannot be edited directly.
Before publishing, review the changes since the last published version. You can also add a description or tags to help identify the version later.
Published versions support the following capabilities:
- Version tracking over time.
- Reuse of published assets across projects.
- Tagging for release and environment management.
- Version-based synchronization in development workflows.
When deploying Experience Builder projects between tenants, you can select a specific published version for deployment.
Published versions
Published versions provide a record of project states that can be reviewed later. Teams can use published versions to track release milestones, identify deployment candidates, and manage content promotion across environments.
When deploying Experience Builder projects between tenants, you can select a specific published version for deployment.
Auto-saved versions
Experience Builder automatically creates project snapshots while work is in progress. These versions support recovery and history purposes only.
Auto-saved versions do not:
- Trigger publish actions.
- Update imported projects.
- Change synchronized application content.
To make changes available for release, manually publish the project.
Revert to a previous version
You can review previously published versions and revert the current project state to an earlier version. Reverting restores the selected version, including its pages, components, styles, and assets.
After reverting, publish the project again if you want the restored state to become the current published version. If you need only specific content from an earlier version, reuse the required assets instead of reverting the entire project.