Avoid Hard-coding Ids in Salesforce

Use Hierarchy custom settings to avoid hard coding in formula field, custom button, process builder or workflow rules

Avoiding hard coded Ids or values from formula field, custom button, process builder, Workflow rules or Approval process using Hierarchy custom setting is not something new. This idea exists from many years in Salesforce ecosystem. However, some times I have seen developers and admins debating on same question, so though to put a consolidated blog post on same.

Why you should avoid hard coded values or Ids in Salesforce ?

Answer is very simple, maintenance. When sandboxes are refreshed or metadata deployed to different instances, admins would need to change values manually. If we are talking about manual post deployment step, then we are also talking about nightmare of maintaining list of manual post build steps.

Can we use Custom Labels to avoid hard coded Ids / values in Salesforce ?

Technically yes, but I would suggest not to use custom labels in Salesforce to avoid hard coded Ids because of below Issues

  •  Dataloader does not support custom label bulk load / restore / export
  • Imagine there are 100’s of custom label and it needs to be different for each Salesforce instances. You would be left either with manual step or some external tool which may not be allowed / approved by customer.

Hierarchy Custom Settings to Rescue

If you are from Java / C#, consider Custom setting as resource file. Here, you would store information about your application which doesn’t change frequently and controls behavior of application. There are two types of custom settings

  • List Custom Setting
    • This custom setting is equivalent to custom / standard object. We can store values in tabular format.
  • Hierarchy Custom Settings
    • This custom setting can be used in formula field, process builder, custom button, Workflow rules or Approval process.
    • Most unique feature about Hierarchy custom setting is that we can have different values at Organization level, profile level and user level.
    • Custom setting can be used in formula fields using global variable $Setup. Syntax to use custom setting is
      
      {!$Setup.CustomSettingName__c.CustomFieldName__c}
      
      
    • Highest priority is given to value defined at user level then profile and at last organization level.

To create Hierarchy custom setting, navigate to Setup | Custom Settings | New.

Youtube Video Demo on Hierarchy Custom Setting

If you want to see action first, then below Youtube video is all yours. Again, don’t forget to subscribe my Youtube channel for latest videos related to Salesforce.

For this article, we are considering below custom setting which contains information about default search word for Google. Custom setting name is Google_Search_term__c and field name is First_Search__c.

Hierarchy custom setting in Salesforce
Hierarchy custom setting in Salesforce

To add value in custom setting, click on Manage.As shown in below image same field First_Search__c in custom setting has different values at Organization level, profile level and user level.

Storing values in Hierarchy custom setting in Salesforce
Storing values in Hierarchy custom setting in Salesforce

Using Hierarchy custom setting in formula field

First example we will see is using Hierarchy custom setting in formula field. Let’s assume, we need to create a hyperlink formula field to search Google on basis of value available in hierarchy custom setting. In this case, running user is Jitendra Zaa and profile is System admin. As per above data, logged in user does not have any value defined at user level or profile level, therefore Organization level value would be considered.

 
HYPERLINK('https://www.google.com/search?q=' &  $Setup.Google_Search_term__c.First_Search__c , 'Search Google')

Above formula is deriving a Google search URL. On URL click, it will open Google search page with default search text as Shiva.

Using Hierarchy custom setting in Process builder

We can use Hierarchy custom setting in process builder either to define criteria or in action.

Below image shows Hierarchy custom setting used as criteria in Process builder :

Hierarchy custom setting in Process builder criteria
Hierarchy custom setting in Process builder criteria

Formula used in above criteria is


NOT(ISBLANK($Setup.Google_Search_term__c.First_Search__c ) )

Below image shows Hierarchy custom setting used as update action

Hierarchy custom setting in Process builder - Record update action
Hierarchy custom setting in Process builder – Record update action

Formula used to update field is


'Field updated from PB - Value in Custom Setting '&$Setup.Google_Search_term__c.First_Search__c

Using Hierarchy custom setting in Workflow rules

We can use Hierarchy custom setting in Workflow rule and Approval process in exactly same way. I would only take example of Workflow rule with the help of images only

Hierarchy custom setting in Workflow rule criteria
Hierarchy custom setting in Workflow rule criteria
Hierarchy custom setting in Workflow rule Field update
Hierarchy custom setting in Workflow rule Field update

Using Hierarchy custom setting in Custom buttons

Below image shows custom button using Hierarchy custom setting.

Using Hierarchy custom setting in Custom button
Using Hierarchy custom setting in Custom button

Formula used is


'www.google.com/search?q=' & {!$Setup.Google_Search_term__c.First_Search__c}

Posted

in

by


Related Posts

Comments

4 responses to “Use Hierarchy custom settings to avoid hard coding in formula field, custom button, process builder or workflow rules”

  1. HariKrishna Sompalli Avatar
    HariKrishna Sompalli

    Thanks for this @Jitendra

  2. Julio Claret Avatar
    Julio Claret

    Hi. I’m not getting the part about “When sandboxes are refreshed or metadata deployed to different instances, admins would need to change values manually.” This is still going to happen, no? If i refresh from prod to a dev sandbox, then the org-level values in dev will be overwritten with the prod ones, and we’ll have to enter dev values again.

    I’m asking because I’m looking for the best way to keep different org-specific values, like callout endpoints. And, also have them available from custom buttons.

    1. Benjamin Pirih Avatar

      Hello Julio, when sandboxes are refreshed the production custom setting values are pushed down from the production instance to the sandboxes. Use custom settings and have a data operation that updates the settings to location specific endpoints. Just envision backing up your custom settings and then restoring them after the sandbox refresh in your dev / testing instances.. Hope that helps..

  3. Monika Watts Avatar

    Hi,,, Can we use custom settings in Triggers ?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from Jitendra Zaa

Subscribe now to keep reading and get access to the full archive.

Continue Reading