Architectural Overview
ExperienceBundleSettings is a mission-critical settings metadata type for enterprise Salesforce DevOps. Historically, Experience Cloud sites (formerly Community Cloud) were packaged as opaque binary .site and SiteDotCom files that could neither be inspected nor cleanly merged in Git version control systems.
Enabling enableExperienceBundleMetadata instructs the Metadata API to serialize Experience Cloud sites as ExperienceBundle structures. This breaks down an entire digital experience into discrete, human-readable JSON artifacts representing routes, views, themes, branding sets, and component configurations—finally bringing modern CI/CD practices to digital community development.
Directory and File Conventions
ExperienceBundleSettings is managed under the Settings metadata family in SFDX projects.
| Property | Value |
|---|---|
| Metadata Type Name | Settings (member: ExperienceBundle) / ExperienceBundleSettings |
| SFDX Folder | force-app/main/default/settings/ |
| File Name | ExperienceBundle.settings-meta.xml |
| Scratch Org Setting | experienceBundleSettings |
Key Metadata Fields
The ExperienceBundleSettings schema contains the primary activation switch:
| Field Name | Field Type | Required | Architectural Description |
|---|---|---|---|
enableExperienceBundleMetadata |
boolean |
Yes | Enables retrieval and deployment of Experience Cloud sites in ExperienceBundle format. |
Note
Once enabled in an org, retrieving ExperienceBundle returns structured directories for each digital experience rather than binary site files.
Declarative XML and Package Manifest Examples
Below is the standard ExperienceBundle.settings-meta.xml configuration file:
<?xml version="1.0" encoding="UTF-8"?>
<ExperienceBundleSettings xmlns="http://soap.sforce.com/2006/04/metadata">
<enableExperienceBundleMetadata>true</enableExperienceBundleMetadata>
</ExperienceBundleSettings>Manifest Definition (package.xml)
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>ExperienceBundle</members>
<name>Settings</name>
</types>
<version>68.0</version>
</Package>CLI Retrieval and Deployment Commands
Retrieve and deploy with sf CLI commands:
# Retrieve ExperienceBundle settings
sf project retrieve start --metadata Settings:ExperienceBundle
# Deploy ExperienceBundle settings to target org
sf project deploy start --metadata Settings:ExperienceBundleArchitect Best Practices and Gotchas
- Deploy Settings First: In CI/CD pipelines deploying into newly spun-up scratch orgs or sandboxes, ensure
Settings:ExperienceBundleis deployed before attempting to deploy anyExperienceBundleorCustomSitemetadata. - Scratch Org Definitions: Always declare
"experienceBundleSettings": { "enableExperienceBundleMetadata": true }within yourproject-scratch-def.jsonfiles to avoid retrieval discrepancies. - Site Publishing Discipline: Deploying an
ExperienceBundleupdates the draft version of the site in Experience Builder. Programmatic or manual site publishing is still required to make changes live for external guest users.
Tip
Pair ExperienceBundle deployments with automated post-deploy scripts using Salesforce CLI (sf community publish) to ensure production changes go live immediately upon build completion.
Frequently asked questions
What does ExperienceBundleSettings enable in Salesforce?
It enables ExperienceBundle metadata format, converting monolithic binary .site and SiteDotCom files into granular, human-readable JSON files.
Why is ExperienceBundle essential for DevOps and CI/CD pipelines?
It decomposes Experience Cloud sites into individual JSON files for routes, pages, and views, enabling Git branching, diffs, and pull requests.
Where is ExperienceBundleSettings stored in an SFDX repo?
It is stored in force-app/main/default/settings/ExperienceBundle.settings-meta.xml and retrieved as Settings:ExperienceBundle.
Comments
Questions, corrections and tips are welcome. Comments are GitHub Discussions, so you sign in with GitHub.