function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
force noviceforce novice 

Custom Settings

What is the difference between Custom Settings & Custom Objects?

Best Answer chosen by Admin (Salesforce Developers) 
Subramani_SFDCSubramani_SFDC

Custom Settings vs. Custom Objects

In some ways, Custom Settings look very much like Custom Objects. In fact, if you use a tool like the Data Loader to view a list of objects in your org, you’ll see that Custom Settings are listed together with Custom Objects, without any visible distinction between the two. However, while both Custom Objects and Custom Settings allow you to define Custom Fields, there are some important differences.

  • Limited field types – Custom Settings support only Checkbox, Currency, Date, Date/Time, Email, Number, Percent, Phone, Text, Text Area, and URL field types. Most notably absent are Formula and Picklist, as well as field types that define relationships to other objects, like Lookup and Master/Detail. You can’t create lookups from Custom Objects to Custom Settings either.
  • No validation rules – You can’t define validation rules on Custom Settings.
  • No workflow or triggers – You can’t define workflow rules or triggers on a Custom Setting. Any validation of data, update of related records, or other actions that you might use workflow or a trigger to perform for a Custom Object have to be implemented differently for a Custom Setting.
  • No page layouts or record types – You can’t re-arrange fields on the page layout for Custom Settings. Custom Settings aren’t really intended to be visible to every-day users. If you need them to be, you can create Visualforce pages to allow users to view and manipulate Custom Setting data.

So if Custom Settings are so limited, why use them?

Avoiding Governor Limits

Depending on how your Apex code interacts with Custom Settings, they can have zero impact on certain governor limits. That’s right – you can retrieve all of the values in a Custom Setting with absolutely no impact on the governor’s count of the number of queries you’ve performed or the number of rows you’ve retrieved.  This makes Custom Settings particularly useful for reference data, like lists of Postal Code / State mappings.

There are a few caveats, however. First, you have to query the Custom Setting in a very specific way in order to take advantage of this “no governor limit” feature. Specifically, you have to use the Custom Setting’s GET methods, not SOQL, to query for data. See the Apex Language Reference for more information. Second, other governor limits, like those on heap size and number of script statements, do still apply. Even with these caveats, though, Custom Settings can provide a welcome relief from the limits on queries and rows.

Hierarchical Access to Data

There are two types of Custom Settings: List and Hierarchy. List-type Custom Settings are very similar to Custom Objects, but Hierarchy-type Custom Settings are very different.  Hierarchy Custom Settings allow you to associate specific rows with specific Users or Profiles. For example, you could define a Hierarchy Custom Setting that associates a different commission rate with different sales reps, with separate rows for each sales rep’s User Id. Then you could add a formula field to the Opportunity object, and reference the Custom setting with a formula like:  $Setup.CustomSettingName__c.CustomSettingFieldName__c.  Whenever someone views an Opportunity record, the formula will be evaluated, and Salesforce will find the Custom Setting row for the currently-running User; if none is found, it will find the row for the current User’s Profile (if one has been defined); and if none is found again, it will find an organization-wide default value (if defined).

This ability to define hierarchical data is very powerful, as it allows you to define user-specific customizations. A common use of Hierarchy Custom Settings is to define application-specific defaults on a user-by-user basis. For example, imagine you’ve developed a Visualforce page displays a list of Accounts, allows the user to select one, and then displays the Cases for that Account. You could store each user’s most recently selected Account in a Hierarchy Custom Setting, and then, the next time the user visits the Visualforce page, it could pre-select the Account that the user selected the last time he was on the page.

All Answers

Subramani_SFDCSubramani_SFDC

Custom Settings vs. Custom Objects

In some ways, Custom Settings look very much like Custom Objects. In fact, if you use a tool like the Data Loader to view a list of objects in your org, you’ll see that Custom Settings are listed together with Custom Objects, without any visible distinction between the two. However, while both Custom Objects and Custom Settings allow you to define Custom Fields, there are some important differences.

  • Limited field types – Custom Settings support only Checkbox, Currency, Date, Date/Time, Email, Number, Percent, Phone, Text, Text Area, and URL field types. Most notably absent are Formula and Picklist, as well as field types that define relationships to other objects, like Lookup and Master/Detail. You can’t create lookups from Custom Objects to Custom Settings either.
  • No validation rules – You can’t define validation rules on Custom Settings.
  • No workflow or triggers – You can’t define workflow rules or triggers on a Custom Setting. Any validation of data, update of related records, or other actions that you might use workflow or a trigger to perform for a Custom Object have to be implemented differently for a Custom Setting.
  • No page layouts or record types – You can’t re-arrange fields on the page layout for Custom Settings. Custom Settings aren’t really intended to be visible to every-day users. If you need them to be, you can create Visualforce pages to allow users to view and manipulate Custom Setting data.

So if Custom Settings are so limited, why use them?

Avoiding Governor Limits

Depending on how your Apex code interacts with Custom Settings, they can have zero impact on certain governor limits. That’s right – you can retrieve all of the values in a Custom Setting with absolutely no impact on the governor’s count of the number of queries you’ve performed or the number of rows you’ve retrieved.  This makes Custom Settings particularly useful for reference data, like lists of Postal Code / State mappings.

There are a few caveats, however. First, you have to query the Custom Setting in a very specific way in order to take advantage of this “no governor limit” feature. Specifically, you have to use the Custom Setting’s GET methods, not SOQL, to query for data. See the Apex Language Reference for more information. Second, other governor limits, like those on heap size and number of script statements, do still apply. Even with these caveats, though, Custom Settings can provide a welcome relief from the limits on queries and rows.

Hierarchical Access to Data

There are two types of Custom Settings: List and Hierarchy. List-type Custom Settings are very similar to Custom Objects, but Hierarchy-type Custom Settings are very different.  Hierarchy Custom Settings allow you to associate specific rows with specific Users or Profiles. For example, you could define a Hierarchy Custom Setting that associates a different commission rate with different sales reps, with separate rows for each sales rep’s User Id. Then you could add a formula field to the Opportunity object, and reference the Custom setting with a formula like:  $Setup.CustomSettingName__c.CustomSettingFieldName__c.  Whenever someone views an Opportunity record, the formula will be evaluated, and Salesforce will find the Custom Setting row for the currently-running User; if none is found, it will find the row for the current User’s Profile (if one has been defined); and if none is found again, it will find an organization-wide default value (if defined).

This ability to define hierarchical data is very powerful, as it allows you to define user-specific customizations. A common use of Hierarchy Custom Settings is to define application-specific defaults on a user-by-user basis. For example, imagine you’ve developed a Visualforce page displays a list of Accounts, allows the user to select one, and then displays the Cases for that Account. You could store each user’s most recently selected Account in a Hierarchy Custom Setting, and then, the next time the user visits the Visualforce page, it could pre-select the Account that the user selected the last time he was on the page.

This was selected as the best answer
souvik9086souvik9086

Adding to the point above Custom Setting stores data in the cache and can be retrieved without repetative queries with zero effect on governer limit unlike custom objects which stores data in database and in which governer limit is ensured.

 

Custom setting is mainly used for string some static datas which can be used very frequently in the application as well as you can built-in hierarchical logic that lets you “personalize” settings for specific profiles or users in the Hierarchy Custom Settings