Custom Settings for Administrators
A few days ago, everybody's favourite man in red who isn't Santa wrote a blog post regarding the use of global variables in formula fields, demonstrating effectively how useful they can be. While reading the article it dawned on me that there may be another, closely related, area of functionality that people are missing out on, arguably because it's often regarded to be found only within developer country. So here's some quick information, along with a demonstration (of possibly dubious efficacy) to show how you can utilise Custom Settings.
What are Custom Settings?
There are two main types of settings, a list (which mimics other objects) or a hierarchy, where values are specific to a user / profile; as you might expect each type offers benefits the other doesn't and meaning they're suited to different use cases. Lists are great for, well, lists.
A list-type custom setting, doing what lists do best and storing a list of values. This custom setting uses the standard name field and one custom field.
From one perspective, custom settings are pretty much the same as any other custom object in that they have a name, a label, and you can add custom fields to them although the list of field types is slightly shorter than the usual; the biggest difference becomes readily apparent when you see how hierarchy custom settings are stored.
The configuration of a hierarchy-type custom setting. This setting only has one boolean (checkbox) field.
So hierarchy-type custom settings records are not stored in the same manner as other objects (at least from the administrator/developer perspective) as they are cached at a higher level than the database; in short, you don't have to pull data from the database when you need them, they're already available for use, and we'll see why this is useful shortly. To manage the data stored in custom settings users must have the "Customize Application" permission enabled in their profile, so typically the data itself is only managed by administrators and they are not utilised in the same way as regular custom objects.
Managing the values for a hierarchy custom setting. Note the default organisation-wide valye, as well as the use of profile and user specific values.
Why Developers Use Them
Developers use custom settings to store lists of data or user-specific settings which are needed in several places, but don't necessarily need to be updated by users, or even at all. They provide a nice level of abstraction in that a developer can use them in code, and they do not get counted towards the governor limits for a request in the same way that SOQL queries are.
They also allow developers to move some small level of maintenance onto an administrator, which is often preferable for both parties as the administrator can keep things up to do date without having to enlist, and wait for, a developer to make a code change.
Using Them Outside of Code
The key benefit to administrators here is that because the settings values are cached outside of the regular database storage, they're available for use in much the same way that global variables are. Because they have a specific value relevant to each user or role, hierarchy settings can be used in formula fields to provide some relevant information to the user about their current situation, a trivial example of which is below.
A formula field definition using a hierarchy custom setting.
The formula on the opportunity page layout.
Also, as you may have guessed, these custom settings can also be used in validation rules so output via formula field as above is even more useful for a user when there is some kind of validation criteria that is related to it. The example below prevents users from being unable to move an opportunity to a closed won stage unless they have 'go ahead' as defined by their particular value for a custom setting.
Creating a validation rule that uses a hierarchy type custom setting.
The same rule in action, preventing a user without go-ahead from closing an opportunity.
As I alluded to in the introductory paragraph, these examples are relatively contrived and also limited in scope, but hopefully they convey the concepts involved, expanding your administrator tool kit and aiding you in your ongoing quest to improve your org for all those that use it.