Salesforce.com’s inclusion of the Custom Settings feature was a much welcomed addition to the Visualforce / Apex feature set. I’ve been using it fairly regularly in my day to day development for close to a year now and I just wanted to share some thoughts on “Best Practices” in how to use these two types.
I have been using Custom Settings, as I’m sure most of you would, as substitute a configuration file. Placing “hardcoded” values into this object and changing out values when needed. Before Custom Settings came out for Apex, we’d use a variety of methods including a “config class”, custom objects, and even custom labels.
Initially, I had used List style custom settings almost exclusively, as it seemed much simpler since it behaved very much like any other Custom Object in Salesforce.com. Also, it was a was fairly similar to my Java experiences where we would create separate config files per environment. So I imagined that I would create a separate config for our production Salesforce.com instance vs. our sandbox instance. But in practice, what would happen more often than not since most of our development was purely native Salesforce.com apps (i.e. Visual force pages which work on data within Salesforce, and are not connected externally to any servers), was once the code was deployed into production, there was very little need for any other configuration other than the production version.
Also, there were times where I wanted to reference these config values outside of Apex code, for example in a formula field or an email template. This is where the Hierarchical Custom Settings has an advantage. Hierarchical can be accessed in other parts of Salesforce.com which may work in conjunction with an Apex package. Formula fields, Workflow Criteria, and Email Templates are examples of things that can access Hierarchical Custom Settings and not List Custom Settings.
Hierarchical Custom settings also have the added benefit of being able to handle those one-off “corner case” users that always seem to come up in large organizations. If you have a user who could benefit from a slightly different app configuration, the Hierarchical Custom Settings is built specifically to handle different config settings for different users.
Update: One really good scenario for using List custom settings are when you have a common reusable piece of code, like for example a custom list view, that you use in many places throughout Salesforce. This list view can be supported by a custom list config where the name signifies where in the app the list appears, e.g. ContactDetail, AccountDetail, AccountListView, etc.
So just to summarize what I feel is the right way to use these different types of Custom settings:
Hierarchical Custom Settings
- Use this for your most of your VF/Apex config settings for stand alone apps
- Don’t put in settings which are environment dependent (e.g. if you have separate test server URLs that should be used in Sandbox vs. Production)
- Definitely, if you are storing User Preferences, Hierarchical is the way to go.
List Custom Settings
- Use this if you creating config for a common piece of code that appears in different areas of Salesforce
- Use this when there are environmental differences such as Test server URLs vs. Production server URLs
- Also can be used as a simple table for frequently used data
Of course you can us a combination of Hierarchical and List settings in your application and use each to its strengths.