Use custom settings to create custom sets of data, or to create and associate custom data for an org, profile, or user.
Available in: both Salesforce Classic and Lightning Experience
Available in: Group, Professional, Developer, Enterprise, Performance, Unlimited, and Database.com Editions.
Packages are not available in Database.com.
User Permissions Needed
To manage, create, edit, and delete custom settings:
Custom settings are similar to custom objects in that they let you customize org data. 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.
Custom settings 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
If you're thinking of using List Custom Settings, consider using Custom Metadata Types instead. Unlike with List Custom Settings, you can migrate the records of Custom Metadata Types using Packages or Metadata API tools.
There are two types of custom settings:
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.
The following examples illustrate how you can use custom settings:
A shipping application requires users to fill in the country codes for international deliveries. By creating a list setting of all country codes, users have quick access to this data without needing to query the database.
An application calculates and tracks compensation for its sales reps, but commission percentages are based on seniority. By creating a hierarchy setting, the administrator can associate a different commission percentage for each profile in the sales organization. Within the application, one formula field can then be used to correctly calculate compensation for all users; the personalized setting at the profile level inserts the correct commission percentage.
An application displays a map of account locations, the best route to take, and traffic conditions. This information is useful for sales reps, but account executives only want to see account locations. By creating a hierarchy setting with custom checkbox fields for route and traffic, you can enable this data for just the “Sales Rep” profile.
You can also include a custom setting in a package. The visibility of the custom setting in the package depends on the Visibility setting.
Only custom settings definitions are included in packages, not data. If you need to include data, you must populate the custom settings using a standard Apex or API script run by the subscribing organization after they have installed the package.