ExperienceBundle for Experience Builder Sites

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.

Limitations

• Managed packages aren’t supported.

ExperienceBundle 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.

For a complete definition of ExperienceBundle and the files it includes, see the Metadata API Developer Guide.

Enable the ExperienceBundle Metadata Type

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 MySiteName1. MySiteName1 now represents ExperienceBundle instead of SiteDotCom.

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}

Retrieve and Deploy ExperienceBundle Using Metadata API

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.

Retrieve and Deploy ExperienceBundle with Salesforce DX

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.