Custom settings in salesforce :

Salesforce Custom Settings

Although Custom Setting is similar with Custom Object, but they are different and for totally different usage. Custom object used to store all data within Salesforce for any transactions, it works similar with standard object, such as: Account, Contact, Opportunity, etc and you can create custom tab for that object.

While custom setting used to store application configurations, such as: value based on each application type or user. You cannot put custom setting data into Salesforce page layout directly as custom object. But, to access custom setting data, you need to access it from: Formula fields, Validation rules, Workflow rules, Apex class, and SOAP API.

There are 2 type of custom setting: List and Hierarchy. Formula field, Validation rule and Workflow only can access Hierarchy type custom setting, while Apex and SOAP API can access both.

Sample to access hierarchy custom setting from formula field or validation rule:
{!$Setup.CustomSettingName__c.CustomFieldName__c}

From SOAP API:
Select p.Description__c, p.Id, p.Name, p.Sign_Date__c from Position__c p
this is very similar with SOQL query to custom object.

Limitation of Custom Setting:

Maximum total data of 10 MB, but if you have less than 10 license users, multiply 1 MB with number of users
300 fields per custom setting.
Can’t share a custom setting record.
No owner assigned for each custom setting record
Each custom setting counts against the total number of custom objects available for your organization.

What are the types of custom settings in Salesforce? What is the advantage of using custom settings?

There are two types of custom settings in Salesforce: List Custom Settings and Hierarchy Custom Settings.

List Custom Settings are a type of custom settings that provides a reusable set of static data that can be accessed across your organization irrespective of user/ profile.
Hierarchy Custom Settings are another type of custom settings that uses built-in hierarchical logic for “personalizing” settings for specific profiles or users.

The advantage of using custom settings is that it allows developers to create a custom set of access rules for various users and profiles.

Custom settings in Salesforce

Custom settings are similar to custom objects and enable application developers to create custom sets of data, as well as create and associate custom data for an organization, profile, or specific user. All custom settings data is exposed in the application cache, which enables efficient access without the cost of repeated queries to the database.

We can create custom setting for storing data similar to custom objects in salesforce but here the data is static.

Similar to custom object, we can create fields in custom setting and after creating the fields, we can click on‘Manage’ button to add records in that custom setting. Then we can use the values in these records in our apex code, validation rules. The benefit of using custom setting instead of custom objects:

Data in custom setting is available in application cache, hence efficient and fast access.

No need to waste SOQL for fetching data from custom setting. There are some methods available in custom settings that we can use to get the data instead of SOQL.

List Custom Setting Methods

The following are instance methods for list custom settings.

Types of custom settings available in salesforce :

You can certainly build your own custom objects to store settings but using custom settings is much quicker (again they are stored in the application cache) and do not count against SOQL limits when fetched. You can also use custom settings in formula fields, validation rules, Apex code and the Web Services API.

Custom settings come in two flavors: list and hierarchy. This post will focus on list custom settings which is the simpler of the two to grok. List custom settings allow you to store org-wide static data that is frequently used. For instance, Salesforce.com does not have ISO country codes baked into the platform. At my last company we maintained this list of countries and their ISO codes in a separate custom object. Whenever we needed the data we'd have to query this custom object which brought with it additional overhead pertaining to the SOQL limits. Using a list custom setting you can now store these codes and use them virtually anywhere needed.

When you create a new custom settings the platform creates a custom object in the background for you (notice the API Name field). You then add additional fields to the custom setting in the same manner that you do for custom objects (you are limited to checkbox, currency, date, date/time, email, number, percent, phone, text, text area and URL fields). I found the management interface for custom settings a little confusing at first and got lost a number of times trying to add fields and/or data.

After you've setup your custom settings and added your fields, you can select the Manage link on the Custom Settings page to add add/edit/delete values. It's very similar to maintaining other records in Salesforce.com.

Once you've finished adding fields and values to your custom settings, you can query it like any other custom object (if you like).

Custom settings have their own instance methods to allow easy access. It looks like the getInstance() and getValues() method returns the same object. I typically use the getInstance() method as it makes more sense to me. You access a record by using the value in the Name column (you cannot use the ID or other columns):

ISO_Country__c code = ISO_Country__c.getInstance('AFGHANISTAN');

To return a map of data sets defined for the custom object (all records in the custom object), you would use:

Map<string,ISO_Country__c> mapCodes = ISO_Country__c.getAll();  
// display the ISO code for Afghanistan
System.debug('ISO Code: '+mapCodes.get('AFGHANISTAN').ISO_Code__c);

Alternatively you can return the map as a list:

List<iso_Country__c> listCodes = ISO_Country__c.getAll().values();

I put together a quick demo on how to use the ISO Countries custom setting in a Visualforce page for a picklist. You can run this example on my Developer Site.

Apex Controller - CustomSettingsListController

public with sharing class CustomSettingsListController {

  public String selectedIso {get;set;}

  public List<selectOption> isoCodes {
    get {
      List<selectOption> options = new List<selectOption>();

      for (ISO_Country__c iso : ISO_Country__c.getAll().values())
        options.add(new SelectOption(iso.ISO_Code__c,iso.Name+' - '+iso.ISO_Code__c));
      return options;

    }
    set;
  }

}

Visualforce Page - CustomSettingsList

<apex:page controller="CustomSettingsListController">  
  <apex:sectionHeader title="Custom Settings" subtitle="List Demo"/>

  <apex:form >
    <apex:pageBlock >

          <apex:selectList value="{!selectedIso}" size="1">
              <apex:selectOptions value="{!isoCodes}"/>
          </apex:selectList>

    </apex:pageBlock>
  </apex:form>
</apex:page>

Note: If you include custom settings in your distributed package you'll need to build in some scripts which populate the settings with data after the package has been installed.

List Custom Settings:

A type of custom setting that provides a reusable set of static data that can be accessed across your organization. If you use a particular set of data frequently within your application, putting that data in a list custom setting streamlines access to it. Data in list settings does not vary with profile or user, but is available organization-wide. Examples of list data include two-letter state abbreviations, international dialing prefixes, and catalog numbers for products. Because the data is cached, access is low-cost and efficient: you don’t have to use SOQL queries that count against your governor limits.

Hierarchy Custom Settings:

A type of custom setting that uses a built-in hierarchical logic that lets you “personalize” settings for specific profiles or users. The hierarchy logic checks the organization, profile, and user settings for the current user and returns the most specific, or “lowest,” value. In the hierarchy, settings for an organization are overridden by profile settings, which, in turn, are overridden by user settings.

In above screenshot, you can see that records in a particular custom setting can be created for particular profile or user. But this is not the case with List custom setting. Records in list custom setting are available for all users and profile in application.

Salesforce imposes certain limits on the amount of cached data and on custom settings:

The total amount of cached data allowed for your organization is the lesser of these two values:
10 MB
1 MB multiplied by the number of full-featured user licenses in your organization

For example, if your organization has three full licenses, you have 3 MB of custom setting storage. If your organization has 20 full licenses, you have 10 MB of storage.

Each Certified managed package gets its own separate limit in addition to your organization limit. For example, if your organization has two certified managed packages installed and your organization has three full licenses, each certified managed package can have 3 MB of custom setting storage, in addition to your organization’s 3 MB custom setting storage limit.

300 fields per custom setting.

You can’t share a custom setting object or record.

No owner is assigned when a custom setting is created, so the owner can’t be changed.

Custom settings are a type of custom object. Each custom setting counts against the total number of custom objects available for your organization.

Custom Metadata Types and Custom Settings Implementation Tricks

Custom Settings

Custom settings helps to create custom data set and associate the data set to particular user, profile or for all users (org-wide).
There are 2 types of custom setting, List and Hierarchy
Same set of data is available to all user if we define List custom setting.
In Hierarchy custom setting, you can control data visibility based on logged in user, profile or org-wide.
In Hierarchy custom setting for logged in user, system first check user then profile and then org wide setting in order to return data from hierarchy custom setting.
You can control the visibility of custom setting by specifying it as public or protected.
If custom setting is marked as protected, the subscriber organization will not be able to access the custom setting. If it is marked as public, then subscriber org can also access it.
Once you create custom setting, then you cannot change the type (List to hierarchy or vice versa).
Custom setting data is available in application cache which increase performance.
You can access custom setting data using instance methods and can avoid SOQL queries to database.
While migrating custom setting to another org, you need to migrate data for custom setting separately.
Custom settings do not support relationship fields.
Custom setting can be used by formula fields, validation rules, flows, Apex, and the SOAP API.
You cannot access List custom setting in Validation rule. Only Hierarchy custom setting can be used.
In order to use value from list custom setting in validation rule, create a field in object and populate list custom setting value in custom field through triggers and then refer it in validation rule. Validation rule fires after trigger execution.
You can perform CUD (Create, Update, Delete) operation on custom setting in apex.
Custom settings are not visible in test class without "SeeAllData" annotation.

Custom Metadata Types

Custom metadata are like custom setting but records in custom metadata type considered as metadata
You can migrate data present in custom metadata type to different org easily.
This helps to create app configuration data and include it in package.
Custom metadata types support Metadata Relationship. It is still in Beta.
Metadata Relationship provides the ability to add relationships from your custom metadata to other things in your app, such as other custom metadata, custom or standard objects and fields, and static resources.
You can't perform CUD (Create, Update, Delete) operation on custom metadata type in apex.
You can also control the visibility of custom metadata type while adding it in package.
Custom metadata type are visible in test class without "SeeAllData" annotation.

Custom metadata types are still in development phase and many new features will come in coming future.

SalesforceVenkat81215

Wednesday, June 28, 2017