Quite a while ago, Salesforce introduced some very significant changes to custom settings. If you aren’t sure what custom settings are please take the time to read my How To Use Salesforce Custom Settings post. This post covers a lot of the changes and when you should start looking at using Custom MetaData Types.

What is is a Custom MetaData Type?
Custom MetaData Types change a lot of things about custom settings. In my mind, the biggest advantage is that the data is deployable and can be managed by a package or by developers without having to write code or sign into the production org and manually set values. This means that the values aren’t really data, they’re metadata and it’s a fantastic improvement for developers and admins. Most Salesforce orgs have dozens or hundreds of custom objects or custom settings that handle configuration. A lot of the time these changes are manually migrated from a sandbox or developer org.

For the most part, custom metadata can do everything that a list custom setting can do. The two downsides that I am aware of are that there’s no native support to create or modify the records within the apex language. I believe this is currently on the roadmap for Salesforce to deliver at some point.

The other downside is that the Custom MetaData Type must be queried unlike the List Custom Setting. Thankfully, the SOQL queries for the custom metadata types don’t count against the number of soql queries.

Common Usages
For most situations, where you used a list custom setting you can probably use custom metadata types. The only caveat with that is they can’t Create Update or Delete done on them without using the MetaData API. For developers working on managed packages, they are a fantastic replacement for storing anything that doesn’t need to be updated by the apex. During the installation process, there’s also no need to write any code to initialize them because the values are deployed with the package.