Salesforce first introduced Custom Settings back in 2009 and since then rarely is there an AppExchange package or solution that does not use them in some form. However, in our client engagements we come across many customers who are still to realize the benefits and have worked around them to date. In this blog our London based Salesforce consultant Ali Zafar explains what they are, the reasons for using them, and how they can be used to improve your change management processes and deployment…
David Liu explains Custom Settings very succinctly on his sfdc99.com blog as “Custom Settings are variables that you use in your code but set and modify outside of your code.” Using Custom Settings appropriately can save you on programmer and CRM admin user’s time.
Custom settings are very useful when it comes to storing static or reusable information in Salesforce, plus it also can work as a switch to turn your application rules ON and OFF. For both Admins and Developers, Custom Settings act as a golden child in the Salesforce family. Under the hood Custom Settings are much like Custom Objects and are accessible via their own API, but you can’t have triggers on a Custom Setting and the available field types are more limited. They do count towards your Custom Objects governor limit however.
There are two types of settings – List and Hierarchical. In this post we are going to look at each of them and suggest typical ways in which you can use them.
List Custom Settings
List settings are structured similar to records held in a custom object. They allow you to store org-wide static data that is frequently used, and therefore cached for performance. Data in List settings do not vary by user and profile, there is no ownership, field level security or record security, and it is available organisation wide (i.e. public for all). It’s best used for data lists, especially reference code lists, and great for when you want to convert code values from one system to another or any other mapping or list.
You may ask why we need to use List settings when same thing can be done through a Custom Object? Well the answer is simple. Custom Settings are stored in the application cache and do not count against SOQL limits when fetched. Also they are much quicker to implement, easier to maintain and they won’t use up one of your precious Custom Tab limits to maintain. They can also only be updated by a System Administrator (or Configure Application profile permission user). Custom Settings have their own methods to access them – we will have a look below at an example on how we can use getInstance() and getAll() methods.
Lets consider a scenario where your customer Service team wants to differentiate between incoming email address with domain names. They want their partner emails to be redirected to different queue with some additional business logic to be applied. For creating a new Custom Settings go to Setup – Develop – Custom Settings, Click New and enter details.
Once you have created the custom setting, you need to define the fields to add to it. The following are the data types that are available for custom settings fields.
In the image below we are storing a few email domain names in custom settings and later fetching them via Apex using getInstance() and getAll() methods. The purpose of this list is to allow us to select the correct Partner details based on company’s domain name. By using the custom setting we can quickly find the mappings we need without querying for a matching field on the Account record (where we may have millions of records).
The following code snippet is an example of one of the ways to use List custom settings in Apex:
In addition to holding lists of static data, List Custom Settings are also useful for:
- Holding environment credentials: Webservice endpoints for production, uat, prepod and dev are likely to be different – don’t hardcode them!
- To hold environment ids: If you have rules, buttons or links that need to utilize specific Salesforce Id values these are going to be different across your environments or may change over time. Rather than hard coding a user or profile id in a Rule, Formula or Apex code you can use a custom setting to hold values such as an ‘Escalation User Id’.
- To hold environment values: You may have rules about opportunities greater than $100k however this limit make change in the future dur to changes in market conditions. Hold the value in a List custom setting if it applies globally to all users (without question) and you need to reference it in Apex. Hold it in a Hierarchical setting if there’s a chance you need to switch it off by user or profile or have different values, or if you need to access the value in a Workflow, Formula Field or Validation Rule.
Custom Settings as a Switch
Hierarchical Custom Settings are defined once and can hold a unique set of values for the Organisation, each Profile or each individual User. Salesforce automatically grabs the lowest level of setting for the running user when a getInstance() call is made, or when accessed in a configuration such as a Validation Rule, Workflow or Formula Field. Note that only Hierarchical settings can be accessed declaratively whereas List settings are for Apex/Visualforce only.
Using hierarchical settings can provide the functionality of a switch, which you can use as ON or OFF to disable Integrations, Triggers, Workflow Rules, Assignment Rules and Validation Rules for all users, specific profiles or individual users. This is possible when you use hierarchical custom settings with a checkbox field to control your system functions, but you could also use it to control internal debugging log levels for example.
Using hierarchical settings lets you control down to an individual user for whom it is de-activated, so you can force a data validation rule for some users and disable it for others. For triggers it is even more useful because triggers cannot be de-activated in a production org without carrying out time consuming deployments (once to switch off and then to switch on again), with no guarantee of how long each deployment will take (depending on the instance queues, org usage and number of unit tests in the org to be run each time).
This becomes especially useful when performing data fixes or data migration, or if needing to disable a failing trigger or Apex functionality in a live org (saving hours in performing the redeployments). Because of the hierarchical nature you can isolate to an individual user, so you could disable all triggers firing during a Data Load for an Admin user to drastically reduce the time to upload data or for an Admin when fixing data errors to switch off emails being sent to customers from Workflows. No more need to deactivate rules one by one and re-activate them when you’ve finished, and work no longer has to always be performed ‘out-of-hours’.
Below is an example of how a hierarchal custom setting can be implemented. You can add new records as Profiles or individual Users to bypass any Apex Triggers or Validation Rules.
In this example we create a validation rule to prevent a User from closing a case with any Open activities, and use $Setup.Your_Custom_Setting with an AND condition in our validation rule to switch this off centrally:
AND
(
ISPICKVAL( Status , “Closed”) ,
ISCHANGED( Status ) ,
Open_Activities__c <> 0 ,
$Setup.MP_Global_Settings__c.Fire_Validation_Rules__c
)
As you can see if you built all your validation rules, workflow rules and triggers using this technique it is an extremely powerful way of controlling behaviour across the entire application.
You can set the default Organisation Level value (as seen in image below) to fire all Validation, Workflow, Assignment and Triggers rules for all Users. To bypass any profile or user, add a record in Custom settings. In the example below only triggers will fire for System Administrator Profile and no rules will fire for User Ali Zafar, even though he is a System Administrator because the lowest level of custom setting is applied automatically. Also, note that the user personal settings will override all his other settings.
This technique can be expanded upon for a number of other reasons:
- To switch application functionality on/off: Useful for orgs with multiple divisions who want different behaviours. Try to create re-usable settings by function such as ‘Reassign Old Leads to Queues’ rather than generic divisional settings such as ‘Run Marketing Rules’.
- To control change management: Similar to the above, when implementing a suite of changes where you need to be able to ‘rollback’ the function in the event of an issue, or you wish to soft launch a feature, consider implementing a Hierarchical custom setting to let you test the change in production for a single user or profile before releasing to all users.
- To provide dynamic page overrides: Different Visualforce or standard pages can be called in a Button or Apex Visualforce Controller based on the Custom Settings for a particular profile or user. This can even be used to include different logos or branding.
- To extend the Profile with custom attributes: Profiles cannot currently be extended with custom fields, so use a Hierarchical Custom Setting to define the fields you need to add at a Profile level. For example, a Sales Commission % field which is used in a formula field. This can then be further overridden by individual user and potentially saving on Profile proliferation!
- To switch Visualforce components on/off: Users can hide sections on Page Layouts but they can’t hide sections on a Visualforce page (ok they can collapse the section but it isn’t remembered between sessions). You can create “Show Financials”, “Show KPIs”, “Show Case History” checkbox options to switch this data off on Visualforce pages using the Rendered attribute to control visibility. Useful when you don’t want to hide the data completely through Field Level Security, just simplify the pages, and very useful for showing different features to Community users by Profile or User and even saving results by user to collapse or hide sections.
Hopefully this blog has inspired you to consider using custom settings more, and you have a better understanding of the different types of custom setting and when each is appropriate. There are some gotchas, but let’s leave those to the next blog…
If you have any questions or want to speak to specialised Salesforce consultants about your upcoming projects, get in touch today.
