Salesforce Custom Settings: Optimizing Your CRM for Maximum Efficiency

What is Custom settings

Salesforce Custom Settings is similar to custom objects, that allow you to create custom data sets and associate them with your Salesforce organisation.

It store data in the application cache, enabling efficient access for various Salesforce functionalities like formula fields, validation rules, Apex, and SOAP API.

Why we use Custom settings

1. It allow to store configuration data including default settings for org, application parameters, or any other custom data that can be used in apex or LWC. 
2. Unlike custom objects, they can be accessed without needing to perform SOQL queries, making them faster and more efficient for accessing configuration data.

Types of Custom Settings
1. List Custom Settings

It provides a reusable set of static data that can be accessed across your organization, It doesn’t vary with profile or user. Examples of list data include three-letter country code abbreviations.

2. Hierarchy Custom Settings

It uses a built-in hierarchical logic that lets you “personalize” settings for specific profiles or users. According to the hierarchy, user settings take precedence over profile settings, which in turn take precedence over settings for an organization.

How to create Custom settings

1. Search for custom settings in Setup Quick Find.
2. Click new and Fill all necessary fields  
3. Save, Finish.

Custom fields in custom settings currently support the following data types:

Checkbox

Currency

Date

Date/Time

Email

Number

Percent
Phone
Text
Text Area
URL

Adding records 

It is possible to designate a user, profile, or custom setting record's owner. This means that when the user executes the Apex class and tries to get a custom settings record, it will take ownership into account and not fetch any records if the user does not own any custom settings records.

In hierarchical custom settings, you can input data at the user, profile, or organisation level. This allows for personalised values based on the user, profile, or general organisation settings.

Accessing custom settings in Apex Class

1. Accessing a List Custom Setting

Getting all datasets in form of map containing all custom fields

Map<String_dataset_name, CustomSettingName__c> mcs = CustomSettingName__c.getAll();

Getting specified dataset containing all custom fields

CustomSettingName__c mc = CustomSettingName__c.getValues(data_set_name);

2. Accessing a Hierarchy Custom Setting

Getting all datasets containing all custom fields for the organization level

CustomSettingName__c mc = CustomSettingName__c.getOrgDefaults();

Getting all datasets containing all custom fields for the specified profile or user

For organisation level
CustomSettingName__c mc = CustomSettingName__c.getInstance();

For specified profile
CustomSettingName__c mc = CustomSettingName__c.getInstance(profileId);

For specified user
CustomSettingName__c mc = CustomSettingName__c.getInstance(userId);

Detailed example on how records are returned with hierarchy restrictions
Let's take below assumptions:
Custom settings name: Hierarchy__c

custom fields: Name__c, Org_Version__c

For the Hierarchy__c custom settings, we have the following 3 records:

1. Organization settings

Context_Name__c = 'Org Name'
Org_Version__c = 'v1.0.0'

2. Profile settings

Context_Name__c = 'System Administration'
Org_Version__c = null (not set)

3. User settings

Context_Name__c = 'Raju'
Org_Version__c = null (not set)

Following demonstrate the results of different methods when Raju calls them with explanation

The results of different fetch methods are shown here, along with an explanation for 3 records. 

1. getInstance() method

The result of the getInstance method when Raju calls it in his organization:

Hierarchy__c CS = Hierarchy__c.getInstance();
System.Assert(CS.Context_Name__c == 'Raju');
System.assert(CS.Org_version__c == 'v1.0.0');

The outcomes remain the same if Raju provides getInstance with his user ID, which is indicated by RajuId. The reason for the same outcomes is that the user-specified custom setting's lowest level of data is set.

Hierarchy__c CS = Hierarchy__c.getInstance(RajuId);
System.Assert(CS.Context_Name__c == 'Raju');
System.assert(CS.Org_version__c == 'v1.0.0');

The outcome is different if Raju gives getInstance the System Administrator profile ID given by SysAdminID. The information provided for the profile is given back:

Hierarchy__c CS = Hierarchy__c.getInstance(SysAdminID);
System.Assert(CS.Context_Name__c == 'System Administration');
System.assert(CS.Org_version__c == 'v1.0.0');

2. getOrgDefaults() method 

The outcome of Raju's attempt to use getOrgDefaults to return the organization's data set is:

Hierarchy__c CS = Hierarchy__c.getOrgDefaults();
System.Assert(CS.Context_Name__c == 'Org Name');
System.assert(CS.Org_version__c == 'v1.0.0');

3. getValues() method

Raju can obtain the hierarchical custom setting values unique to his user and profile settings by utilizing the getValues function. For instance, the following happens if Raju gives getValues his user ID, RajuId:

Hierarchy__c CS = Hierarchy__c.getValues(RajuId);
System.Assert(CS.Context_Name__c == 'Raju');
// Note how this value is null, because you are returning
// data specific for the user
System.assert(CS.Org_version__c == null);

The following happens if Raju gives getValues his System Administrator profile ID, SysAdminID:

Hierarchy__c CS = Hierarchy__c.getValues(SysAdminID);
System.Assert(CS.Context_Name__c == 'System Administration');
// Note how this value is null, because you are returning
// data specific for the profile
System.assert(CS.Org_version__c == null);

Deployment of custom settings 

1. Only custom settings definitions are included in packages, not data. To add data, you must use Apex Code which should be executed after the package get installed.

2. The subscribing organization cannot use Apex to update or view custom settings if their privacy is protected and they are part of a managed package.

Limitation with custom settings

1. We can't transfer list custom settings records using packages. Instead, we can use custom metadata, which allows easy migration of records using packages or metadata API tools.
2. You can create a maximum of 100 records for a single custom settings.