The ExperienceBundle metadata type provides text-based representations of the different settings and components, such as pages, branding sets, and themes, that make up an Experience Builder site. Whether it’s for your own org or you’re a consulting partner or ISV, you can quickly update and deploy sites programmatically using your preferred development tools, including Salesforce Extensions for VS Code, Salesforce CLI, or your favorite IDE or text editor.
Before the Summer ’19 release (API version 45.0 and earlier), the Network, CustomSite, and SiteDotCom metadata types combined to define an Experience Builder site. However, retrieving the SiteDotCom type produces a binary .site file that isn’t human readable. By retrieving the ExperienceBundle type instead of SiteDotCom, you can extract and edit granular site metadata in a human-readable format, contained in a three-level folder structure.
When you retrieve ExperienceBundle, the data is stored in a three-level folder structure.
The experiences folder contains a folder for each Experience Builder site in your org. Each site_name folder—customer_service in this example—contains subfolders that define the site and represent the different elements that you access in Experience Builder. Each subfolder has .json files that contain the properties that you can edit on your local machine or scratch org and then deploy.
Let’s take a closer look at the files that define each Experience Builder site.
| Folder | Contents |
|---|---|
| brandingSets | branding_set_name.json defines the site’s branding set properties. |
| config |
|
| An SPA is a web app that loads a single HTML page. Unlike a traditional website, which comprises several pages that the user navigates between, an SPA consists of multiple views that update the page dynamically as the user interacts with it. | |
| routes | Contains one file per page, named page_name.json, which defines the URL and other route-related information. |
| themes | Contains one file per theme, named theme_name.json, which defines the theme. |
| variations | Contains one file per variation, named experienceVariation_name.json. You can use an experience variation to change the default behavior of an Experience Builder site based on the audience, such as branding, page variations, component visibility, or component attributes. |
| views | Contains one file per view, named view_name.json. Each file defines an SPA view, which is equivalent to a page to the end user. A view consists of regions that contain other regions or components in the rendered page. |
Before you update the .json files of an Experience Builder site, we recommend making a copy of the site’s folder as a backup.
Tip
For a complete definition of ExperienceBundle and the files it includes, see the Metadata API Developer Guide.
After you enable ExperienceBundle for Aura sites, Metadata API calls (retrieve and deploy) and Salesforce DX operations (pull, push, and status) use the ExperienceBundle type instead of SiteDotCom.
If you use change sets to deploy your site, the list of dependencies includes two items of type Site.com—MySiteName and _MySiteName_1. _MySiteName_1 now represents ExperienceBundle instead of SiteDotCom.
You don’t need to enable the ExperienceBundle metadata type for LWR sites. LWR sites use ExperienceBundle by default.
Note
Digital Experiences in the Quick Find box, and then select Settings.Alternatively, you can enable this feature when creating a scratch org using a scratch org definition file. (See the Metadata Coverage report.)
1{
2 "orgName": "Sample Org",
3 "edition": "developer",
4 "features": [
5 "COMMUNITIES"
6 ],
7 "settings": {
8 "experienceBundleSettings": {
9 "enableExperienceBundleMetadata": true
10 },
11 "communitiesSettings": {
12 "enableNetworksEnabled": true
13 }
14 }
15}In Metadata API, a manifest file defines the components that you’re trying to retrieve. This example shows a package.xml manifest file for retrieving an Experience Builder site using ExperienceBundle instead of SiteDotCom.
1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3 <types>
4 <members>*</members>
5 <name>CustomSite</name>
6 </types>
7 <types>
8 <members>*</members>
9 <name>ExperienceBundle</name>
10 </types>
11 <types>
12 <members>*</members>
13 <name>Network</name>
14 </types>
15 <version>46.0</version>
16</Package>After you retrieve the .zip file, unzip it to access and edit the files.
See Deploying and Retrieving Metadata with the Zip File.
Salesforce Developer Experience (DX) is a set of tools that streamlines the entire development lifecycle. It improves team development and collaboration, facilitates automated testing and continuous integration, and makes the release cycle more efficient and agile.
If you’ve set up your Salesforce DX environment, you can quickly:
sf project retrieve startsf project deploy startsf project deploy preview or sf project retrieve previewsf community list templatesf community createsf community publishIf you’re not familiar with Salesforce DX, check out these great resources.
See Also
j