If you have delved into the world of custom objects in the Salesforce platform, you have more than likely used Custom Objects to interact with your Apex code, and, depending on your permissions, even had your APIs call on those custom objects. Amazing, right?

There is another level to custom objects called Custom Settings which, for some reason, loads of developers either aren’t aware of or simply don’t understand, despite their ease of use and practical applicability. Although not as powerful as Custom Objects, Custom Settings are a definite must-have and deserve their rightful place in your organization. In fact, if you use Data Loader or something similar, you will notice that both Custom Objects and Custom Settings are listed together. Custom Settings are a special type of Custom Object, with fewer bells and whistles. Custom Objects are record tables, while Custom Settings are configuration tables.

But how are Custom Settings better?

It’s not that simple. Think of Custom Objects as a chainsaw, and Custom Settings as a scalpel; each has its specific use and purpose even though they are very similar in function.

Let’s start off by discussing what these two have in common before we get to the eureka moment and realize how amazing Custom Settings are: Custom Objects and Custom Settings both allow developers to create custom sets of data in addition to creating and associating custom data for a user, profile, or organization.

You can define custom fields in both, but Custom Settings has fewer field types (only checkbox, currency, date, date/time, email, number, percent, phone, text, text area, and URL). Specifically, Custom Settings don’t have some of Custom Objects’ great custom fields such as Formula, Picklist, or relationship-defining Lookup or Master/Detail. There are also no lookups from Custom Objects to Custom Settings.

There are no page layouts or record types for Custom Settings, so you are not able to re-order fields in your page layout, and for the most part, these are not meant to be seen by your average Salesforce user. You can allow for some user manipulation of this data, but you will have to create Visualforce pages to do so.

There is also no defining of validation rules, workflow rules, or triggers in Custom Settings. Any data validation or related records updates that you might normally use a Custom Object to trigger must be implemented differently for a Custom Setting.

But wait, these all sound like drawbacks. I thought you said there would be a eureka moment about how great Custom Settings are?

Get ready for it:

Custom Settings data is stored in the application cache, which enables efficient access without the cost of multiple repeated queries to the database. In fact, using Custom Settings avoids Governor Limits almost completely. As long as you query the Custom Settings using GET methods rather than an SOQL query you can retrieve all of the values with literally zero impact on the governor’s count of the number of queries performed or rows retrieved. This means that you will want almost all of your reference data to live life as a Custom Setting rather than as a Custom Object since the limits allow only 100 SQL queries and 150 DML operations maximum per transaction before resulting in an error. Keep in mind that other Governor Limits such as heap size and a number of script statements do still apply, but aside from these, Custom Settings can really help out with limits on queries and rows. (To dig into other ways to avoid exceeding governor limits, check out Apex Best Practices – Avoid Exceeding Governor Limits)

Moreover, there are actually two different types of Custom Settings: List and Hierarchy.

A List Custom Setting is very similar to the way Custom Objects work. It caches your data, meaning access to data is low-cost and efficient, and there is no need to use SOQL queries that count against the aforementioned Governor Limits. The data in this type of setting does not vary between users or profiles and is available across the entire organization. All in all, this provides a reusable set of static data that can be accessed across your organization, particularly for sets of data that are frequently used within your application.

For instance, the developer enabled the State and Country Territory Picklists in the org and implemented a custom page that overrides the input of users for their account record address. You can utilize the custom settings so that in the page it would show the State Names and whenever the record is saved, the equivalent State Code is processed in Salesforce. Using custom settings makes the functionality easier to main for the developer would not need to update the custom page controller for any additional State Codes he can just configure this in the custom settings. 

A Hierarchy Custom Setting, on the other hand, is exactly why you want to use Custom Settings. It uses an integrated hierarchical logic that allows you to personalize settings for – and associate-specific rows with – specific profiles or users. It checks the organization, profile, and user settings for the current user and returns the most specific value, or the lowest value in hierarchical rank (if undefined or otherwise stated). The settings for an organization become subject to the specific profile settings in use which in turn become subject to the individual user settings in use, kind of like a hierarchy. This ability to define hierarchical data is extremely powerful and is commonly used to define application-specific defaults on a user-by-user basis.

For example, you could define a Hierarchy Custom Setting that associates different points of contact within an organization depending on the level or role of the user. So, if you want your CEO to have direct contact with the Organization ABC’s CEO, this field will automatically appear as his or her organizational contact, whereas lower-level employees in your organization shouldn’t have that kind of direct access, instead of having their contact field populate with their appropriate point of contact. So your sales manager has their acquisition manager as their contact, your shipping manager has their warehouse manager as their contact, and so on so that if your shipping manager needs to escalate something with Organization ABC, they cannot simply look up and call the CEO without first escalating it internally. This can be set by the profile in use or even as specifically as the user, with the default point of contact being Organization ABC’s front desk. This logic can extend to rates of pay or commission amongst sales reps, to types and level of detail for shipping information depending on how much or how little of this information is required by different organizational departments.

Wow, awesome! But how exactly do I utilize a custom setting?

Unleash the power of custom settings using the Custom Settings Methods, just as used in the examples above.

These are instance methods that operate on a specific custom setting instance. There are different methods for each type of custom setting.

A quick table listing out the available methods:

getInstance() and getValues() methods return the same values for List Custom Setting but may not return the same for Hierarchy Custom Setting.

For more information, visit: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_custom_settings.htm

There’s more to custom settings!

Though custom settings do not have formula fields or validation rules, their data can be used in formula fields and validation rules.

Overall, when you combine the power of Hierarchy Custom Settings with the desirability of avoiding Governor Limits, while still having much of the same application and value of Custom Objects, it is easy to see why Custom Settings are a wonderful tool worth exploring and deploying in your organization.