"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. Philosophically, you can argue that no, one should not delete stuff from git, but we found that this was the only way to avoid having the tool add the "ghost" files from the previous version to the current deployment.

One way to detect the problem is by looking at your promotion branch in the git UI. Any files where the most recent commit is not the one you just made, is likely to cause this problem. That was the only way we found to detect the errors prior to deployment.

Another technique is to simply delete all the files from the destination branch in the views, variations, and routes folders. It's a blunt instrument, but you do have a copy of that version in its promotion branch should you need it.

Now, why Salesforce is reusing ID's, that's a real mystery.

Comments

Popular posts from this blog

Setting a DateTime to a Weekday in a Formula

"Disjunctions not supported" - Why Custom Metadata and Flow Don't Mix

Update Knowledge Articles in Bulk