Deployment Experience Cloud via Metadata API — SiteDotCom & ExperienceBundle

Metadata API deployment of the experience cloud site or community is always tricky, even if you do via changeset. I have come across so many challenges in my various project while moving the community/Experience site from one environment to another.

I would like to share my experience and some tricks which may be helpful for you while deploying a site between an environment.

There are 2 approaches when moving the Experience cloud site between sandboxes.

• ExperienceBundle
• SiteDotCom

SiteDotCom was the traditional approach that salesforce use, the component was binary nonhumane readable. ExperienceBundle was recently added by the salesforce team and trust me it’s so great to understand your site in a SPA(Single Page Application) structure but it is still buggy .

Let’s first understand the other 2 component which is common whether you would like to pick an approach ExperienceBundle or SiteDotCom.

1. CustomSite
2. Network

Network — This contains administration settings, such as page override, email, and membership configurations.

CustomSite — Contains the domain and page setting information, including indexPage, siteAdmin, and URL definitions.

Network, CustomSite components should be part of the retrieve and deployment package XML.

Package.xml for retrieval/deployment of the site using SiteDotCom assume your site name is “Experience Cloud Name”

Package.xml for SiteDotCom

In the members attribute of the component, if you noticed there is “_” under the CustomSite and “1” at the end for the SiteDotCom.

Challenge with SiteDotCom deployment.

• You need to manually create the site with the same name as the one you are trying to deploy to a higher environment if this is a first-time deployment.
• When you deploy the site, manually publish the newer version of the site.
• If you rename a site in Administration | Settings, make sure that the source and target sites have matching values for the picassoSite and site attributes in the Network component.
• If you are upgrading the existing site and deploying to another sandbox, kindly re-verify the menu navigation.
• You cannot read the SiteDotCom, as that is a binary file — So you always need to make a change on the sandbox and retrieve the file. I am the kind of person, who likes the XML version of the component and where I can read/edit the component as per requirement and know what individual aspect we are deploying.

The answer of the above challenges is ExperienceBundle component but there is some issue but there is a workaround as well.

Understand the ExperienceBundle Component

ExperienceBundle component is nothing but a bunch of .json files which contain the property and SPA(Single Page Application) view, routes, etc.

Note- If you are not aware of SPA architecture, don’t worry will cover some of the aspects of it.

When you retrieve the experience bundle component via package.xml, under the experience components there are other subcomponents

• brandingSets
• config
• routes
• themes
• views

Package.xml for retrieval/deployment of the site using ExperienceBundle assume your site name is “Experience Cloud Name”

Package.xml ExperienceBundle

Let’s go one by one to each subcomponent

1. brandingSets

This subcomponent contains the .json file about the branding sets used during the site development and the “id” attribute is used while referring to the branding in the theme component.

2. Config

This subcomponent contains *.Json files. The files come under the Config folder mainly related to the configuration of the site e.g language etc.

3. Themes

Themes subcomponents contain *.json files which represent the theme of the site.

4. Routes

This is one of the important components of the ExperienceBundle, which helps you to understand how to your navigation link with the Views (will discuss in the next pointer). Let me walk you through with an example

So this is the route JSON for the accountList route,

• here “activeViewId” is the ID of view this route refers under the View Component.
• Id is the route component id.
• Label is the Name of the Route
• urlPrefix is the URL of the site which will reflect the path /

5 . View

This subcomponent contains all the View JSON files.

Means the Site page you see/develop as part of your project and this provides all the information, let me walk you through the one file to explain it.

I know there is too much on the View Json file, but if we see closely, it breaks the entire page in the components. Very similarly to how we see the page in the builder — like header, footer, and the components you added on the page.

In the above example if you see the collapsed components section, you can see the header, then tabset, record component followed by the information about the view like name type and theme.

So, if you add any new page on the Site, it will create a new file under the “route” and “view” folder.

Any components added to the view should reflect as components on the view file.

Challenges around ExperienceBunddle

I want to say, I love how the salesforce allows us to see the site in those JSON files. So you can understand your page, components, and any changes. It’s so great you can review the code of your team in the PR.

But ExperienceBundle there are a few challenges I would say it is still a little buggy and the salesforce team needs to work on it.

These issues, because when you have an enhancement on the existing site.

• When you have Dashboard on your component

You may get an error for any

“The recordId property of component 2eabbaec-f46c-4c60-ab7b-f60e4837d416 references an object with the ID value 01Z2I000000bFcKUAU. Occasionally, when deployed to a destination org, ID values can become invalid — for example, if the referenced ID doesn’t exist in the destination org. If you encounter component issues in your destination org, verify that the ID values are correct.”

This error is because you refresh your sandbox from the production and the dashboard id doesn’t match. Workaround removes the dashboard and saves the page. Add the same dashboard again and retrieve the dashboard. This would update the id of the dashboard.

I know this is a buggy portion I didn’t like how it tagged with the id rather name and having dependency when you do the deployment between different sandboxes. I would say if this doesn’t solve your problem raise a case with the salesforce. I hope they would change the structure and would rather use name instead of id in the future API release.

Note — My case with salesforce is still open at this time, and R&D team is working/researching on it. I hope in the near future this will be fix in one of the release or R&D team would suggest something else.

• When you have ListView on your component, you would get the same record ID error.

Fix is you would remove the id reference and use the List view name instead of Id.