Newer Version Available

This content describes an older version of this product. View Latest

ExperienceBundle for Lightning Communities (Developer Preview)

The ExperienceBundle metadata type provides text-based representations of the different Community Builder settings and site components, such as pages, branding sets, and themes, which make up a Lightning community. Whether it’s for your own org or you’re a consulting partner or ISV, quickly update and deploy Lightning communities programmatically using your preferred development tools, including Salesforce Extensions for VS Code, Salesforce CLI, Workbench, or your favorite IDE or text editor.
Available in: Salesforce Classic (not available in all orgs) and Lightning Experience
Available in: Developer Edition

Prior to 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.

The ExperienceBundle metadata type is available as a developer preview. ExperienceBundle isn’t generally available unless or until Salesforce announces its general availability in documentation or in press releases or public statements. All commands, parameters, and other features are subject to change or deprecation at any time, with or without notice. Don't implement functionality developed with these commands or tools. You can provide feedback and suggestions on using ExperienceBundle in the Community Cloud group in the Trailblazer Community.

Note

Developer Preview Limitations

  • ExperienceBundle is available for Lightning communities in Developer orgs only, and can’t be used to deploy Lightning communities to a production org. However, you can deploy a community to another Developer org.
  • Developer orgs don’t support change sets.
  • You can’t enable ExperienceBundle in scratch orgs using a definition file. Instead, enable the feature in Community Settings.

ExperienceBundle Structure

When you retrieve ExperienceBundle, you get the following three-level folder structure.

The experiences folder contains a folder for each Lightning community in your org. Each community_name folder—customer_service1 in this example—contains subfolders that define the community and represent the different elements that you access in Community Builder. And within each subfolder are .json files containing 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 Contains branding_set_name.json, which defines the community’s branding set properties.
config Contains:
  • site_name.json, which defines several community settings, such as public access and progressive rendering
  • languages.json, which defines supported languages
  • loginAppPage.json and mainAppPage.json, which are single-page applications. loginAppPage.json is used for community pages that require login and mainAppPage is used for all other pages.

    A single-page application (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
views Contains several files that each define an SPA view, which is equivalent to a page to the end user. A view is made up of regions that contain other regions or components in the rendered page. The folder contains one file per view, named view_name.json.

See the Metadata API Developer Guide for a complete definition of ExperienceBundle and the files it includes.

Enable the ExperienceBundle Metadata Type

To start using ExperienceBundle, you must enable it. After you enable the feature, Metadata API calls (retrieve and deploy) and Salesforce DX operations (pull, push, and status) use the ExperienceBundle type instead of SiteDotCom.

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

After you enable the feature, to use the Salesforce DX pull operation with communities that previously existed, you must make an update to the community in Community Builder. For new communities that you create after you enable the feature, the pull operation works as expected.

Note

Retrieve and Deploy ExperienceBundle Using the Metadata API

In Metadata API, a manifest file defines the components that you’re trying to retrieve. The following sample shows a package.xml manifest file for retrieving a Lightning community using ExperienceBundle, rather than 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 life cycle. 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 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.
If you’re not familiar with Salesforce DX, check out these great resources.