Wednesday, January 23, 2013

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.

Related Posts


  1. I think custom settings have some fantastics uses. I blogged about using them in validation rules last year:

    1. I like that use case, skipping validation when you need to can be enormously helpful!

  2. I use Custom Settings to create custom types rather than code them. This is useful when I'm sending completely customised, processed data based upon multiple objects to a VisualForce page. The Custom Setting itself will therefore simply be a blank public list. I find this easier and clearer rather than coding it up. I've never seen anyone else doing this - do you reckon this is bad practice?

  3. That's an interesting use of them! I'm sure some people probably would call this bad practice, but to me it sounds like good ol' lateral thinking. If it was a custom object I think it would be considered worse, but since custom settings are kept neatly tucked away I really like this idea, will give it a go myself sometime.

  4. Regarding the use of Custom Settings to create custom types, I've found that there is something to be cautious of. Happily, I managed to stump SF Premier Support with this before figuring out for myself what was going on.

    You can certainly use Custom Settings to quickly build a custom type to display data. However, you can't dynamically allow the user to temporarily update any of the created records in your new list unless they have the "Customize Application" privilege, which is highly unlikely to be the case for everyone.

    So, if you want to put some checkboxes alongside each of your dynamically created records (e.g. to allow the user to select then create a bunch of tasks simultaneously for each record in the list), DO NOT store this checkbox on the Custom Setting. It will work for you as a System Admin, but it won't work for most of your users. You'll therefore need to stick to the standard practice if you're doing anything like that.

    1. To clarify my last post (as I'm just completing the project where I came across the issue), you can use Custom Settings as an easy way to create and manage a custom data structure for displaying in a VisualForce page. Your users won't be able to update these temporary records, but if you need this (such as for the task creation idea above), you'd just include the Custom Setting, along with the dynamic variable(s) in a wrapper. It totally works, and it rocks.