Stupid Salesforce Tricks

 It's pretty opaque how Salesforce handles Invocables when using an Apex-defined type. In my use case I am trying to create a generic utility that returns a bunch of stuff that you can't get in Flow. Achieving this is pretty unforgiving and I found it very confusing, so here's my attempt to demonstrate it in plain English.

If you are creating links in a formula, you want them to work in sandboxes. If you have a URL like: https://myOrg--sbox.sandbox.my.salesforce.com If you use: "https://" & mid($Api.Enterprise_Server_URL_500,9,(FIND("/",$Api.Enterprise_Server_URL_500 ,9)-8)) You will get: https://myorg--sbox.sandbox.my.salesforce.com/ Or, for Communities, "https://" & mid($Api.Enterprise_Server_URL_500,9,(FIND("/",$Api.Enterprise_Server_URL_500 ,9)-8)-15)&"site.com"   Note: For Communities if you have a custom domain you should first check for whether you are in production, because your custom URL won't fit the pattern. This works by: Start with the literal string "https://" Find the mid substring where: The URL is the Enterprise Server URL Starting at location 9 (after https://) For length  Using FIND Find the first slash after location 9 subtracting 8 characters for https:// In the Community version, we pull out the "sale...

 If you follow the principle of least permissions -- and you should -- then it should make you cringe a bit to grant someone admin permission in production. System Administrator allows anyone with that permission to pretty much do whatever they want. That cuts both ways, where it removes obstacles to people's day to day, but also creates risks for honest mistakes and even bad-actor behavior. We're working on how to structure permission for our admins and devs so that they can do their day job, but remove permission to change metadata since that needs to go through DevOps. Cloning the System Administrator Profile and removing "Customize Application" is a start. But as your org changes, you have to make sure that permissions are added to the cloned Profile as fields are created. Basically, we need a way to ensure "Modify All Data" includes permissions to all objects, fields, tabs, etc. To facilitate this, as a little side project I've created an Apex class...

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>             ...

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 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.

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!

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...

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.

 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. Philo...