Let me lead off by saying that this post will be a little different from some of the others as it’s more of a conglomerate of notes on Custom Settings than tips & tricks. It’s also a work in progress and will continue to expand as my understanding of Custom Settings evolves. Lastly, this will be a focus on List-type Custom Settings, and perhaps sometime down the road I’ll write about Hierarchy-type Custom Settings.
What are Custom Settings?
Custom Settings are either lists of field sets or hierarchy definitions that you can access from processes and formulas (Salesforce Help – Custom Settings). Each Custom Setting is an object wherein you can define your own fields, however, unlike an object there aren’t records created based on those fields. It sort of looks like there is, but in actuality each “record” is just a new field set that is available for your process.
Types of Custom Settings
There are two types of Custom Settings: Lists and Hierarchies.
List Custom Settings
This type of Custom Setting is the easiest to understand as it looks and behaves just like any custom object you would create.
What is the Advantage of Using Custom Settings?
Custom Settings are brought into the application cache so the information is available platform-wide. Additionally, since there isn’t a need to access the database for this information, queries to Custom Settings do not count against SOQL limits.
What is an Application Cache?
An Application Cache is a temporarily block of memory that is used to store a collection of data that duplicates original values stored elsewhere. You can think of a cache as a dictionary that was created from existing information in a database.
Why Use an Application Cache?
It all has to do with speed and access. Queries to a database can take more more time than queries to data in memory. Furthermore, access to database information may come with restrictions, but access to cache information is platform-wide.
Why is it Such a Great Deal?
I didn’t really understand why Custom Settings were so cool at first. They can be a little clunky to work and seemed much easier to just use a custom object. But the advantage to using Custom Settings finally settled in one day was when I was writing a Flow and needed to enclose a Lookup within a Loop. This is a big no-no as you run the risk of hitting your SOQL limits if your loop will be traversed very many times. Then I remembered that queries to Custom Settings won’t count against the query limit so they would be save to use in this scenario and that’s when it all fell in place for me:
- Custom Settings are fast
- Custom Settings are platform-wide
- Custom Settings do count against the SOQL limit
- Custom Settings are cool
Custom Settings Limitations
One limitation is that new settings cannot be created by a process. Therefore, if you have a process that may generate new items you will need to use a custom object instead.
For example, I have a Flow that uses a dynamic picklist for the user to select a job title. If the job title needed doesn’t exist, however, the user can select a choice which will enable them to enter a new job title. This new job title is then added to the list before the Flow ends so it is available the next time. Because new information is being added to the list I had to use a custom object instead of Custom Settings.
Considerations For Using Custom Settings Versus a Custom Object
Dynamic Choices in Visual Flow
I use both Custom Objects and Custom Settings for creating dynamic choices in Visual Flow. My criteria for deciding which to use is based on how fluid the information is and whether or not the process will create additional items. For example, if I have an established picklist field I know that those picklist values are not going to change much, if at all, so creating Custom Settings for these lists is a great choice. On the other hand, if I have a list that may expand, or the information is still being developed, I’ll use a custom object.
Who Will Maintain the List?
Another consideration is whether or not the System Administrator will be the only individual who will maintain the list, or if other users will be involved. When other users are involved a custom object makes the most sense because you can create a page layout, App, and other features which will make it easier for those users to access and update.
- Wikipedia – How a Cache Works
- Salesforce Help – Custom Settings
- The Platform Cache
- Using List Custom Settings in Salesforce