Salesforce Apex Coding

Remarks

Introduction

Unlike custom objects which have records based on them, custom settings let you utilize custom data sets across your org, or distinguish particular users or profiles based on custom criteria. This means, for example, that admins can edit hierarchy custom settings to deactivate Workflow / Validation Rules for single users or profiles, without having to switch them off for the whole org (see the Using Hierarchy Custom Settings To Disable Workflow / Validation Rules example above).

Validation rules commonly need to be disabled temporarily when:

• Code is updating old records, which were last edited before a validation rule was activated & therefore don’t meet the newer rule’s criteria.
• Code is inserting new records without the values required by a validation rule’s criteria.

Workflow rules commonly need to be disabled temporarily when:

• They would trigger an Email Alert or Field Update which would overwrite or interfere the changes you are making to the record.

Use of a custom setting grants admins some declarative control over code so one of the many use cases is that when utilized, they can make it unnecessary to deploy code in order to disable triggers (see the Using Hierarchy Custom Settings To Disable Apex Code example above).

A key benefit for developers is that custom setting’s data is exposed in the application cache, which enables efficient access without the cost of repeated queries to the database. This data can then be used by formula fields, validation rules, flows, Apex, and the SOAP API – see the Salesforce documentation.

The limits & considerations for custom settings are documented here.

List Custom Settings

It is possible to create List Custom Settings too, common use cases include storing two-letter state abbreviations, international dialing prefixes, and catalog numbers for products. However Salesforce is now promoting the use Custom Metadata Types, instead of List Custom Settings.

When you go to create a new Custom Setting, the following message will be displayed

Tip: Use Custom Metadata Types for App Configuration

If you’re thinking of using list custom settings, consider using custom metadata types instead. Unlike list custom settings, you can migrate the records of custom metadata

types using using packages or Metadata API tools.

Custom Metadata Types have additional benefits vs List Custom Settings as described in this answer. And according to the lead developer of CMDs “There’s a lot more planned for custom metadata types than custom settings on steroids.”

Examples

Creating & Managing Custom Settings

Creation

To create a Custom Setting, go to:

Classic

Setup > Develop > Custom Settings > New

Lightning

Setup > Custom Code > Custom Settings > New

Create your setting (see the Remarks later in this document for the differences between Hierarchy & List custom settings). You can ignore the Visibility picklist, unless you plan to deploy your setting in a managed package.

To create your setting fields click the New button and follow the usual process for creating a custom field.

Management

Once you have created your field(s) you can start configuring the setting by clicking the Manage button.

It’s easier to manage the setting if you create a new view and include any fields that you’ve created to give yourself a comprehensive overview of the setting, at a glance. The Setup Owner is the user or profile that the setting applies to.

To manage the setting at the org level, click the New button above the Default Organization Level Value header (in red box below).

To manage the setting at the user or profile level, click the New button in the blue box below.

Using Hierarchy Custom Settings To Disable Workflow / Validation Rules 

Custom Setting 

Custom Setting Field

Custom Setting Field Value

Validation Rule

The rule can also be disabled for a whole Salesforce org –

In the above rule, both pieces of criteria must evaluate to TRUE in order for the rule to be triggered.

Since All_Opportunity_Disabled  c checkbox will evaluate to TRUE when the running user’s profile is System Administrator, the rule will evaluate to FALSE.

Workflow Rules

The same approach can be applied in order to deactivate Workflow Rules.

Using Hierarchy Custom Settings To Disable Apex Code

Explanation

In this example a simple Trigger has been created to change the Close Date of an Opportunity, that’s about to be inserted or updated, to a date 10 days in the future.

The Apex Controller custom setting’s checkbox field enables the code to be disabled at the user / profile / org level.

Apex Class

Unit Test

Updating Hierarchy Custom Settings in Apex Code

You may wish to update your custom setting’s during the execution of your code, to switch off validation or workflow rules.

In the below code, I have created a Schedulable Apex Class which will update the Close Date of any Opportunities whose Close Date is less than or equal to 6 days from the current date, changing the date to 20 days in the future.

I will use my Custom Setting Val_Rule_Cntrlr c to deactivate any validation rules which would prevent me from updating the Opportunities that meet my criteria.

To make sure that my validation rules are being deactivated by the changes to my custom setting in my class, I have created a checkbox field Trigger_Validation_Rule  c (which would not be visible to users or added to page layouts) & a validation rule with this criteria:

I then set the checkbox field to true when creating my Opportunities so that the rules criteria would be met, if the custom setting field is not edited by my code.