New Communities
If you're deploying a brand new community to an org that doesn't have communities enabled, then you must first set NetworksEnabled as a part of the OrgPreference Settings metadata.
When you create a community for the first time Salesforce will generate some Apex classes, EmailTemplates, and Visualforce pages automatically. These are used to facilitate self-registration, logging in, and notifying community members.
Deploying Communities
To deploy Communities, there are a few necessary pieces of metadata:
Network - The core Community/Experience settingsCustomSite - Settings for a Site like whether it's Active or has a URL Prefix.ExperienceBundle - this is a newer metadata type that replaces the cumbersome SiteDotCom metadata. See Experience Bundles below.SiteDotCom - this is a binary file that contains most of a Community's content (pages, assigned layouts, components on the page and their set values). Note that you can't really compare this because it's binary and in order to deploy this to a target the source must be on the same API version as the target otherwise your deployment is dead on arrival because the only solution is to wait for the target to upgrade. Also note that simply fetching this metadata from the Salesforce Metadata API can generate a brand new MD5 hash so it's difficult to tell if there are differences between two communities. I recommend not dealing with this metadata type.
Experience Bundles
If you have ExperienceBundle enabled for your community (under Setup > Digital Experiences > Settings), then the ExperienceBundle metadata consolidates branding and unreadable content of the SiteDotCom metadata into a folder of JSON files.
If you have ExperienceBundles enabled (you can verify this by checking for the ExperienceBundle.settings-meta.xml file and that enableExperienceBundleMetadata is true) then the only types of metadata that need be included in a manifest file are:
- ExperienceBundle
- Network
- CustomSite
Example:
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>*</members>
<name>CustomSite</name>
</types>
<types>
<members>*</members>
<name>ExperienceBundle</name>
</types>
<types>
<members>*</members>
<name>Network</name>
</types>
<version>54.0</version>
</Package>
The metadata for branding & page configurations are included under the ExperienceBundle experiences directory. An example bundle directory will look like:
experiences/
├─ experience1/
│ ├─ brandingSets/
│ ├─ config/
│ ├─ routes/
│ │ ├─ home.json
│ ├─ themes/
│ ├─ variations/
│ ├─ views/
├─ experience1.site-meta.xml
SiteDotCom (Legacy method)
If you are not using Experience Bundles, then the metadata for branding includes (look and feel):
NetworkBranding - core community branding, such as the login page colors and backgroundBrandingSet - for branding themes (colors, fonts, brand image)ContentAsset - asset file metadata, like a logo image
Additional Metadata
Finally there are a few optional pieces of metadata related to Communities:
Audience - if you're using audience targeting, this is the rulesetCSPTrustedSite - allowed external sites used if you are embedding outsides scripts, images, or frames into your community.Community (Zone) - Used for Ideas and Chatter AnswersKeywordList - a list of banned words in a community
Using any tools that access the Metadata API (ANT & Gearset come to mind, but pick your preferred tool) should allow you to compare all of these pieces of metadata together to spot differences with the exception of SiteDotCom. With differences in the source and target, you'll probably need to either construct a unique deployment file (to merge changes from both into one) or align all the changes in QA and then deploy to production.
