Salesforce.com introduced Custom Settings in Winter ’10 which allows you to store custom data sets and associate them on an org-wide, profile or user basis. Custom settings data is exposed in the application cache and do not count against SOQL limits when fetched. This data can then be used by formula fields, validation rules, Apex, and the SOAP API.
Custom Settings support only Checkbox, Currency, Date, Date/Time, Email, Number, Percent, Phone, Text, Text Area, and URL field types. You can’t create 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 Page layouts, record types, validation rules, triggers and workflow rules can be used on Custom Settings.
There are two types of custom settings:
List Custom Settings: It 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.
Hierarchy Custom Settings: Hierarchical Custom Settings are defined once and can hold a unique set of values for the Organization, each Profile or each individual User. Salesforce automatically grabs the lowest level of setting for the running user when a getInstance() call is made, or when accessed in a configuration such as a Validation Rule, Workflow or Formula Field. Only Hierarchical settings can be accessed declaratively whereas List settings are for Apex/Visualforce only.
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.
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.