Newer Version Available
ExperienceBundle for Lightning Communities (Developer Preview)
| Available in: Salesforce Classic (not available in all orgs) and Lightning Experience |
| Available in: Developer Edition |
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.
| Folder | Contents |
|---|---|
| brandingSets | Contains branding_set_name.json, which defines the community’s branding set properties. |
| config | Contains:
|
| 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.
- From Setup, enter Communities Settings in the Quick Find box, and then select Communities Settings.
- Select Enable ExperienceBundle Metadata API.
- Save your changes.
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.
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.
- 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.