Posts

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: https://myorg--usertest.sandbox.my.salesforce.com in a sandbox, or https://myorg.my.salesforce.com 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 Site.com was included in the deployment. When the Site.com 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

Image
 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

Creating a ZIP File for Salesforce on a Mac

 A few posts out there about how the Mac Zip utility won't create a ZIP file with the proper data structure. This one was given to me by a friend and it worked well. I used this to create a deployment package, but I imagine it would work for static resources as well. zip -r What-You-Want-Your-Zip-File-To-Be-Called.zip ./Folder-With-Your-Content -x "__MACOSX" -x ".*" 1. Navigate to the parent folder in Finder (the folder that "Folder-With-Your-Content" is in). Say, it's called "Deployments." 2. Hold down Ctrl and right click the parent folder. Then choose "New Terminal at Folder." 3. You will get a new Terminal window with the name of your folder and a % sign, e.g., Deployments % Then paste the command above, swapping out the two values for your real folder names.

Free Utility: StringUtilities

I've created a utility that will allow you to invoke any of Apex's String methods from a Flow.  Hope this is useful to some of you out there. I've provided very straightforward instructions on how to use it -- Although this is code, there are no code skills required to use it. View on GitHub