Community Deployments: Duplicate Priority Values

When deploying a Community (Experience Cloud) with Audiences, we sometimes get an error like this: Remove duplicate priority values.Details:Personalization Target Info ID - 6At3C000000HaltSAC,Target Type - ExperienceVariation,Target Value - Home_Theme_Navigation_Menu_3_Component_Properties,Group Name - 3f555c74-248d-4f2c-a8b2-5d27fc4814c0$#$7be51a96-6390-4437-99f0-d1e9072649a7,Publish Status - Draft,Group Priority - 9 What's going on here is that the priorities you set in your Audiences are stored across the Audience files. You'll see in the Audience that there are multiple target nodes:         <target>             <groupName>ecdea109-1ddb-4b66-9452-ebc43120220b$#$7dce6e95-ba15-4481-bb64-e6fd08f79488</groupName>             <priority>1</priority>             <targetType>ExperienceVariation</targetType>             <targetValue>2023_Home_English_Section_Component</targetValue>         </target>  The short answer to th

Limitation: Permission Sets in Permission Set Groups For Community Membership

A note on Community membership granted by Permission Sets in Permission Set Groups -- per Salesforce Support: If you have a Permission Set that grants membership to a Community, for the Community membership to apply, you must apply that Permission Set directly to the User. If the Permission Set is in a Permission Set Group, applying the Group only will not apply the Community membership. #SalesforceWorksExcept ....

Deploying Audiences - Don't Change the Display Name!

 Deploying Audiences with your Community can be an odyssey. In our case we got this error: [ ] An unexpected error occurred with   gack Id 2077957683-448881 (1131023739). Try again or contact your Salesforce admin for help. This idiosyncratic and cryptic error made our heads spin. It turned out that the display name of the Audience had been changed. Even though you'll see an API name for it in the metadata, when it does deployment checks, something is going on where it expects the display name to align to the API name. In our case, we changed the naming convention of our Audiences. When "Canada (French)" became "Market - Canada - French" in the UI but the API name remained "Canada_French", it failed to deploy and we got that ugly-as-sin error. We had two options: to live with a nonconforming name, or rebuild the Audience. We chose the latter.

Getting the Root URL in a Formula Field

If you're dynamically constructing a URL in a formula field, you can use the following for the root: left($Api.Enterprise_Server_URL_500,find(".com",$Api.Enterprise_Server_URL_500)+4) That will give the base URL regardless of whether you're in a sandbox or production. For example, it will give: in a sandbox, or in production Easy peasy. Don't hard-code URL's!

API Version Considerations in Community Deployments

We just went through a deployment of a big update to Communities. There was some heartburn prior to the launch that it would fail because our prior environment was a preview sandbox and thus on a higher API version than prod. Documentation says "You can’t deploy to a target org that’s using an earlier release version." This is one that was challenging since there is very little information out there, so I hope this helps someone. We tested this by deploying from a higher sandbox to a lower one and it went fine. There were no errors or warnings.  In the end we found that this a problem only when (1) deploying from a preview sandbox to a production org on the lower version, and (2) when the was included in the deployment. When the is included, you get a deployment error:  Sorry, your target org is running on an earlier version of Salesforce and can't accept the current file. Please wait for your target org to be updated and try again. We also received th

Community Deployment: "The priority is higher than the maximum stored priority."

We got this error when deploying Communities. The priority is higher than the maximum stored priority. Use a lower priority.Details:Personalization Target Info ID - 6At8G0000004M8ASAU,Target Type - ExperienceVariation,Target Value - Home_ESMX_Theme_Navigation_Menu_8_Component_Properties,Group Name - d9b26ca9-27fd-4ac1-a965-d4c7e0a32bbb$#$16ddf820-1ec5-4e9d-beed-950c2814e4de,Publish Status - Draft,Group Priority - 9 There is very little information on the Google machine about this error specifically. We found that we got this error because we did not include all our Audiences in the deployment.

"component IDs must be unique" when deploying Communities

 Communities are notoriously difficult to deploy. One error we ran across that was maddening was the following: Several components in Support_Community/views/2023SearchEnglish.json , Support_Community/views/2023SearchClientCommunity.json share the same ID, but component IDs must be unique. Replace the following duplicates and try again. 77200210-1d47-414e-b202-8b72cc746faa ExperienceBundle is a group of JSON files. It's meant to be deployed a one thing to wholly replace the one in your destination org, just like any Apex class or other metadata. We found that in our case, Copado was inserting files from the destination branch that were no longer present in the ExperienceBundle.   Apparently, files in a subsequent export of the ExperienceBundle are likely to include duplicate IDs to those in prior versions, thus the conflict. The solution was to go into git and delete the file from the destination branch, so Copado didn't have anything to merge into our current promotion. Philos