ExperienceBundle for Lightning Communities (Pilot)

The ExperienceBundle metadata type provides text-based representations of the different Community Builder settings and site components, such as pages, branding sets, and themes, that make up a Lightning community. Whether it’s for your own org or you’re a consulting partner or ISV, you can quickly update and deploy Lightning communities 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 a community. 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 community metadata in a human-readable format, contained in a three-level folder structure.

We provide the ExperienceBundle metadata type to selected customers through a pilot program that requires agreement to specific terms and conditions. To be nominated to participate in the program, contact Salesforce. Pilot programs are subject to change, and we can’t guarantee acceptance. ExperienceBundle isn’t generally available unless or until Salesforce announces its general availability in documentation or in press releases or public statements. We can’t guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available products and features. You can provide feedback and suggestions on using ExperienceBundle in the Community Cloud group in the Trailblazer Community.

Note

Pilot Limitations

Unlocked packages and managed packages aren’t supported.
The CMS Collection, CMS Connect (JSON), and CMS Single Item components aren’t included in ExperienceBundle.

ExperienceBundle Structure

When you retrieve ExperienceBundle, the data is stored in a three-level folder structure.

The experiences folder contains a folder for each Lightning community in your org. Each community_name folder—customer_service in this example—contains subfolders that define the community and represent the different elements that you access in Community Builder. Each subfolder has .json files that contain the properties that you can edit on your local machine or scratch org and then deploy. ExperienceBundle folders

Let’s take a closer look at the files that define each Lightning community.

Folder	Contents
brandingSets	`branding_set_name`.json defines the community’s branding set properties.
config	`site_name`.json defines some community settings, such as public access and progressive rendering. languages.json defines supported languages. loginAppPage.json and mainAppPage.json are single-page applications (SPA). loginAppPage.json is used for community pages that require a login, and mainAppPage is used for all other pages. 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	The variations folder is available only to participants of a separate Personalization pilot program. To be nominated to participate in the Personalization program, contact Salesforce. Pilot programs are subject to change, and we can’t guarantee acceptance. Personalization isn’t generally available unless or until Salesforce announces its general availability in documentation or in press releases or public statements. We can’t guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available products and features. Note Contains one file per variation, named `experienceVariation_name`.json. You can use an experience variation to change the default behavior of a Lightning community based on the audience, such as branding, page variations, or component visibility.
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.

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, 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 community, the list of dependencies includes two items of type Site.com—MyCommunityName and MyCommunityName1. MyCommunityName1 now represents ExperienceBundle instead of SiteDotCom.

From Setup, enter Communities Settings in the Quick Find box, and then select Communities Settings.
Select Enable ExperienceBundle Metadata API.
Save your changes.

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 a Lightning community 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. Zip file contents

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.

If you’ve set up your Salesforce DX environment, you can quickly:

Retrieve all the communities in your org using sfdx force:source:pull
Deploy updates using sfdx force:source:push
Check for conflicts or changes on the server using force:source:status

After you enable the feature, to use the Salesforce DX pull operation successfully with existing communities, you must first update the community in Community Builder. For new communities created after you enable the feature, the pull operation works immediately.