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
