Stupid Salesforce Tricks

 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>             <targetType>ExperienceVariation</targetType>             <targetValue>2023_Home_English_Section_Component</targetValue>         </target>  The short answer to th

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.