Deploy Salesforce Communities via SFDX

Deploy Salesforce Communities via SFDX

2022, Aug 21    

A while ago I wrote a blog about Deploying Salesforce Communities via ANT…. Now is the time to demystify Community or rather Digital Experience Cloud deployment and SDLC.

While working with scratch orgs with sfdx, the CLI is very good at pulling or deploy/redeploy our changes to site or audiences changes to another scratch orgs. However, once we try to deploy our source to another type of an org, Developer, Sandbox or production we find there are metadata issues. This blog will explore how to resolve these for moving source from scratch orgs to developer sandboxes etc.

Chicken or Egg?

In sfdx project metadata files for Network, DotComSite and Site are kept in separate directories networs & sites. These two are dependency on each other as far as sfdx deployments go. Trying to deploy one then the other we get errors that prevent our deployments to move forward. This especially problematice in CICD type setup.

In field: Name - no Network named My Portal found

or we get this error deploying Network before Site:

In field: Site - no CustomSite named My_Portal found

Solution to this problem is deploy all items together. In VSCode using command key on MacOS higlight all 3 directories sites, networks siteDotComSites and select dropdown menu option SFDX: Deploy Source to Org. Result is succesfull deployment to sandbox or dev org.

Community Builder error

=== Deployed Source
STATE    FULL NAME     TYPE        PROJECT PATH
───────  ────────────  ──────────  ─────────────────────────────────────────────────────────────────
Created  My_Portal   CustomSite  force-app/main/default/sites/My_Portal.site-meta.xml
Created  My_Portal1  SiteDotCom  force-app/main/default/siteDotComSites/My_Portal1.site
Created  My_Portal1  SiteDotCom  force-app/main/default/siteDotComSites/My_Portal1.site-meta.xml
Created  My Portal   Network     force-app/main/default/networks/My Portal.network-meta.xml

Site owner and Site admin

There is additional detail to cleanup, with scratch orgs creating new site automatically assigns your default admin user as Site Admin and owner. When deploying to other types of org, NOT a new scratch org, there will be an error since there is no such user exists in target org.

Before run deployment need to delete these tags from My_Portal.site-meta.xml

<siteAdmin>NOT-EXISTING-USER@example.com</siteAdmin>
<siteGuestRecordDefaultOwner>NOT-EXISTING-USER@example.com</siteGuestRecordDefaultOwner>

Otherwise we can expect an error similar to this one:

=== Deploy Errors
PROJECT PATH                                            ERRORS
──────────────────────────────────────────────────────  ───────────────────────────────────────────────────────────────────────
force-app/main/default/sites/My_Portal.site-meta.xml  In field: siteAdmin - no User named NOT-EXISTING-USER@example.com found

Final words on metadata

The Digital Experience (former Community) site itself is managed in the following metadata components

  • Network - Community settings XML file
  • CustomSite - Associated site settings XML file
  • SiteDotCom - Site content, binary blob autogenerated for community
  • Audience - Built audiences added in recent releases
  • Content Assets - images content setup on site
  • Navigation Menus - site navigation menu
  • NetworkBranding - branding parameters for the main site (does not include page variations) and need to prefix cb<Name>

In SFDX project these components are managed or pulled from scratch org into their own respective directories or folders.

force-app/main/default
	audience
		Default_My Portal.audience-meta.xml
	contentassets
		<Holds vrious asset files such as logo, background images etc.>
	documents
		<Experience shared folders>
	navigationMenus
		Deafult_Navigation.navigationMenu-meta.xml
	networkBranding
		cbMy_Portal.networkBranding
		cbMy_Portal.networkBranding-meta.xml
	networks
		My Portal.network-meta.xml
	siteDotComSites
		My_Portal1.site
		My_Portal.site-meta.xml
	sites
		My_Portal.site-meta.xml

Once we deploy main site components, all other items can be pushed as separate items without any issues. In conclusion sfdx cli makes deployment of Experience sites simpler.