What's the best practice for deploying changes to Experience/Community pages from sandbox to prod? In this case, we've changed some pages in sandbox and meanwhile others have been changed in prod. So we don't want to deploy the ExperienceBundle wholesale, or we'll revert the changes that were made in prod.

Is there any way to do this cleanly, either with change sets or with a tool like clickdeploy? Or do we first need to manually apply the prod changes in sandbox, and then deploy the whole ExperienceBundle?

I can't be the only one who needs to do this, so guessing there's a simple answer I've just missed.


  • 2
    You might be able to use a tool like Gearset or Clickdeploy to compare and deploy the metadata. In some situations, Gearset can merge different changes in the same XML file, but in others it may overwrite one side with the other. May 20, 2021 at 15:11
  • @DavidCheng thanks! I tried clickdeploy and there's no obvious way to do it there, but may try gearset.
    – mscholtz
    May 20, 2021 at 19:58

2 Answers 2


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 settings
  • CustomSite - 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


<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">

The metadata for branding & page configurations are included under the ExperienceBundle experiences directory. An example bundle directory will look like:

├─ 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 background
  • BrandingSet - 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 ruleset
  • CSPTrustedSite - allowed external sites used if you are embedding outsides scripts, images, or frames into your community.
  • Community (Zone) - Used for Ideas and Chatter Answers
  • KeywordList - 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.

  • Thanks, nbrown. Seems like your last sentence is the real rub for me. Was hoping I could avoid that kind of semi-manual compare/merge prior to deploy, but sounds like it's not avoidable.
    – mscholtz
    May 21, 2021 at 18:06

@mscholtz In the case of Sites, In order to export Experience Pages You can go to Digital Experience from Settings. Then Goto All Sites -> Workspaces -> Administration -> Pages -> Go to Site.com Studio enter image description here

Then at the Right Top, you can find settings where you can export from Source Org then deploy to your destination Org.

enter image description here

  • 1
    Doesn't answer the OP's question - he has different changes in both sandbox and production. Also this Site.com export method is obsolete and does not capture all community items. May 20, 2021 at 15:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .