Custom settings and custom metadata are highly similar concepts within Salesforce. As you may know, Salesforce occasionally develops features that serve similar purposes, such as Process Builder and Flows, and eventually opts for a single solution. A comparable situation arises with custom settings and custom metadata – they can achieve similar objectives. So, why did Salesforce create these distinct features? The answer is straightforward: because they can! Just kidding. Custom settings were introduced prior to custom metadata, so we could say that custom metadata is a sort of evolution of custom settings. This is, of course, a significant oversimplification, so let’s quickly compare these features:
| Custom settings | Custom metadata | |
| Suffix | “__C”, similar to a Salesforce custom object | “__mdt” |
| Types | List or Hierarchy | Does not support hierarchy based on Profile or User |
| Deployment | You have the flexibility to move your custom setting structure (metadata) using standard deployment approaches. However, it’s important to note that transferring the actual data within the custom setting, whether through packages, the Metadata API, or change sets, is not supported. Sad but true: you would need to move the records manually. | Custom metadata types outshine custom settings in the sense that they offer the capability to deploy both metadata structure and data/records using change sets. |
| Supported field types | CheckboxCurrencyDateDate/TimeEmailNumberPercentPhoneTextText AreaURL | The same as supported by Custom Settings minus: Currency plus: Metadata Relationship – creates a relationship that links this custom metadata type to another metadata type, entity definition, entity particle, or field definitionPicklistText Area (Long) |
| Formula fields, validation rules, Flows usage | Can be used by Salesforce formula fields, validation rules, and Flows. | Can be used by Salesforce formula fields, validation rules, and Flows. |
| Apex usage | You can perform CUD (create, update, and delete) operations on custom settings in Apex. Not visible in test class without “SeeAllData” annotation. Custom settings data can be accessed using instance methods, which allows you to avoid making SOQL queries to the database. | You can’t perform CUD (create, update, and delete) operations on custom settings in Apex. Visible in test class without “SeeAllData” annotation. You can get the custom settings with SOQL. |
| API usage | SOAP API | Use SOQL to access your custom metadata types and retrieve the API names of the records of those types. |
Table 3.1: Custom settings versus custom metadata comparison
As we’ve discussed, there are some similarities between both features. Before we take a side and recommend the best feature, let’s take a closer look at each of these features, including how to create them.