Custom Settings: Shortcuts for Salesforce Admins

Custom Settings are not just useful for Developers. While it’s true that Custom Settings can be used with Apex code and the SOAP API, they can also be used in the declarative (point-and-click) interface to reduce the number of places you need to make changes, making your org more efficient and easier to manage.

Consider Custom Settings when you:

1. Use the same constant value in more than one place such as workflows, formulas, validation rules, and approval processes.
2. Need varying permissions on a function, based on your org’s hierarchy.
3. Already use the $Profile or $User globals in your rules or formulas.

Because Custom Settings are stored in the Salesforce application cache, they don’t count against your query limits. However, they are considered as Custom Objects, so they do count against your object limits. Review these Salesforce Custom Settings Limits and Considerations before creating them.

Custom Settings are available in all org types and were first introduced in the Salesforce Winter ’10 Release. To create and manage them, you need the “Customize Application” permission.

Custom Settings contain fields just like Custom Objects do. These fields are the actual “settings” that you can reference in formulas, validation rules, and workflow. We’ll look at how to do this once we review the types of Custom Settings.

There are two types of Salesforce Custom Settings: Hierarchy and list.

Hierarchy Custom Settings

If you are already using the Salesforce Global Variables $User and $Profile in your formulas, workflows, and validations, a Custom Setting may simplify managing their values. Hierarchy custom settings are used in business cases where some users or profiles have varying levels of permissions.

Some examples of Hierarchy Custom Settings include:

1. To set an amount that might later change – for example, percent discount.
2. To set thresholds for approval processes – for example, all users can approve deals up to $1,000,000, but only those with the Manager profile can approve deals over $1,000,000.
3. To display an extended help message, depending on a user’s preference.

List Custom Settings

List Custom Settings are reusable static data sets that you manage in one place. Because they are org-wide, they are visible to everyone.

Some examples of List Custom Settings include:

1. The two-character state codes. (While you could achieve this with Salesforce: State and Country picklists, available since the Spring ’13 beta release, because of the conversion effort involved, some orgs still prefer to use Custom Settings.)
2. Environmental IDs and variables.
3. Shipping and handling costs by weight class.

As of this writing, List Custom Settings are not available at the declarative level so we won’t spend time on them in this blog. Feel free to promote the administrative availability of List Custom Settings on the Salesforce Idea Exchange!

Use Case for Hierarchical Custom Settings

Hierarchical custom settings provide a global baseline for certain values which can then be modified by creating additional levels of permissions at the User or Profile level.

Let’s say that your org has a fourth-quarter push on sales and is allowing customers under certain campaigns to qualify for deals. You have a custom object called Deals with a Master-Detail relationship to Opportunities. On the Deals object, there is a currency field called Deal Amount.

We’ll consider the following parameters for the example:

1. Deals are typically $100-$200 off the price, but can be increased up to $500 by anyone who can create a Deal record.
2. Deals that are more than $500 off the price must be approved by someone with the Contract Manager profile or by Rose Gonzales who is in Sales Operations.
3. Deals that are more than $1500 off have to be approved by Ian George, the Sales Manager.

So, you create an approval process on your Deals object, and the logic looks something like this:

The formula logic is getting complicated, and several components need to be updated if anything changes, such as:

1. The Sales leaders decide to change the deal limits.
2. As the quarter wraps up, there’s a need for more designated approvers.
3. Rose get a promotion and someone else takes over her Sales Operation position.

What if you could include all of the logic in the above formula with just this one line?

Deal_Amount__c < $Setup.Globals__c.Deal_Amount__c

Read on to see how to do this.

To create Hierarchical Custom Settings (Example)

1. Under Setup, choose App Setup => Develop => Custom Settings.
2. Click New to create a new setting

3. Give the Custom Setting a Label and an Object Name (these can be the same).
4. For Setting Type, select Hierarchy.
5. Set the Visibility to Public. Click Save.

You would select “Protected” for the Visibility when you need a Custom Setting that can be used by the Salesforce org, but is neither visible, nor editable – for example, for managed apps.

6. Click New in the Custom Fields section to create a new custom field within the Custom Setting.

7. Create a currency field on the Custom Setting, called Deal Amount, with length 16 with 2 decimal places and save.
8. Now return to the Globals Custom Setting Definition screen and click Manage to add the Deal Amount values.

9. When you set the values for the Custom Settings, you can specify global values for your entire org (with the New button at the top), and additional values per user or per profile (with the New button lower down).

Click the top New to set the global value first.

10. Set the Deal Amount for your org’s default. In this case, it’s $100.

This can be used to set the amount on a newly created deal (and overwritten as needed). See Step 15.

11. Navigate back to the Globals Custom Setting and then click New in the lower section of the screen to add a record to override the global value for a specific profile.

12. For either a Profile or a User, we can specify a value for the “Deal Amount” and that value will be globally-available in your org. Select Profile, then “Contract Manager” in the Profile lookup field. Now set the Deal Amount to 1500 for permission to approve deals up to $1500. Click Save.

13. Navigate back to the Globals Custom Setting and click New in the lower section of the screen again to add another record, like you did for the Profile. Select User, then “Rose Gonzalez” in the User lookup field. For Rose, we have also granted the permission to approve deals up to $1500.

14. In the actual Deal Custom Object, you can set the value of the deal amount field to be the Deal Amount specified in the Globals Custom Setting:

15. Then, when someone who doesn’t have any special hierarchical permissions creates a new Deal record, the default amount is what we set in the Globals Custom Settings for the org: $100.

16. The same Custom Setting can be used to build the approval logic that was getting complicated before.

This logic (you have to scroll to see all of it!) …

Can now be replaced with this:

Get Out of Validation Free Pass!

Most Salesforce Admins who load data into their Salesforce orgs have been stopped by their own validation rules from time to time. Deactivating all validation rules … and then remembering to re-activate them … can be time-consuming and error-prone.

Examples of validation rules you might want to override as an Admin:

1. Opportunity Close Dates cannot be in the past.
2. If the Opportunity is lost, the Lost Reason must be supplied.
3. If the Case Reason is set to the Other, than the Other Reason field is required.
4. Leads must have a Lead Source.

Data from legacy systems or from earlier in your Salesforce org’s use may not meet these rules. Rather than deactivating validation rules every time you load data, you can use Custom Settings in the validation rules to make the System Administrator profile (or any Profile or User) exempt.

You can create an Admin Permissions Custom Setting with an Admin Override field and use it to bypass validation rules by System Admins. In the validation rule, you set …

$Setup.Admin_Permissions__c.Admin_Override__c {the names of your custom setting and field}

… to “not true” (false) as one of the criteria for the validation rule. For System Admins, this criterion is always true, so the validation does not fire and the record can be saved.

To create an Admin Override Custom Setting

1.Create a hierarchy Custom Setting and set its visibility to public. We are calling the Custom Setting “Admin Permissions.” Click Save.

2.Click New in the Custom Fields section on the Custom Setting you just built.

3.Make the new Custom Field a checkbox. Click Next. Name the field and leave the default “Unchecked,” and save. We are calling it Admin Override, for example.

4.Click Manage on the Admin Permissions Custom Setting, and then click New in the Default Organization Level Value area. This is where we add records that will have different values for the setting, either at the Profile or the User level.

5.Select Profile in the drop-down and choose System Administrator. Select the Admin Override field for this profile. Click Save.

6.This setting will work, for example, if you need to load legacy Cases that took place before the requirement for the “Other Reason” text field (when Case Reason = “Other”). Just exclude the System Admin from that validation rule by adding the condition …

NOT ($Setup.Admin_Permissions__c.Admin_Override__c)

… to the validation rule.

7.The conditions for the validation rule to be true (so the record can’t be saved) are:

1. The Case Reason = “Other”
2. The Other Reason is blank
3. The $Setup.Admin_Permissions__c.Admin_Override__c is false

The last condition is met when the user saving the record does not have the profile of System Administrator, and hence cannot override the validation rule. If the user is a System Admin, the third condition is not met; therefore, the validation rule does not prevent the record from being saved.

That’s how System Admins can “get out of validation free.”

Using the Admin Override in Workflow

This Admin Override Custom Setting can also be used in workflow and approval processes.

For example, your org could have a Workflow Rule that creates a Task for the Opportunity Owner when the Opportunity Stage becomes “Value Proposition.” But you may not want to assign the tasks if a System Admin owns the Opportunity.

In the Rule Criteria section of the workflow, instead of running the rule when “criteria are met,” choose to run it when the “formula evaluates to true” (if not already selected).

Then you can add the Admin Override setting to the workflow criteria the same way we did for the validation rule in the earlier example.

Summary

Hierarchical Custom Settings have administrative applications that can save you time and reduce the number of places you need to make updates. In our example, instead of building out detailed logic in an approval rule, we used a Custom Setting to define the thresholds for the different users’ permissions. We also built the Admin Permissions Custom Setting, which allowed the Admin Override field to be set by user or profile, which we could then use to exempt those designated from validation rules, workflow, and the like.

The applications of this include:

1. Varying functionality based on who is accessing it.
2. Increasing levels or permission – one application is to roll out functionality gradually.

If you have a need for hierarchical values or permissions, consider building them in Custom Settings as a centralized place to manage their values.