What is the difference between Custom Settings and Custom Metadata Types

  • Summer '15 is going to include the GA release of Custom Metadata Types. See Introducing custom metadata types: the app configuration engine for Force.com

    Are Custom Metadata Types intended as a complete replacement for Custom Settings?

    I gather from the article linked above that the big advantage to Custom Metadata Types is that a baseline collection of metadata records can also be deployed in packages.

    Are there other advantages? Such as support for lookup relationships or protected values that can only be accessed my code within the managed package? Is there such a thing as hierarchy custom metadata types?

    Are there advantages to using Custom Metadata Types with respect to limits? In particular SOQL limits?

    See also: How to use custom metadata types to save years of development on app configurations

    I think the custom settings will still stay and the main purpose will be the hierarchy access. The custom metadata types will replace the list custom settings. You mentioned the biggest advantage, you can deploy them and package them. In regards to SOQL, it won't count towards the limits as it's cached metadata.

    @Bachovski I've almost always used hierarchy custom settings for config or lists that are going to have vastly different values for each org (hence being in config). I feel like I'm missing something about the custom metadata types where I've never thought I needed to deploy actual list values. If CMTs are really just ListCustomSettings++ then why not just extend them in place? I guess they need to support both.

    I agree that they should've extended the list custom settings if this is the case. My take on this is that there will be more functionality coming up for the custom metadata types in the future, and if they eventually replace the custom settings, for the time being, we'll be seeing both.

    @Daniel - I agree that this feature (at least for now) appears to be a bit of a head-scratcher. If instead we just had the ability to deploy data as part of a package, including Custom Setting and Custom Object rows, that would appear to do almost everything that this new feature offers. I have to wonder whether is some future roadmap around custom metadata that makes it more meaningful than just basically ListCustomSettings++. I also think that "Apex Tests see all records without SeeAllData" could cause problems for config-dependent tests.

    @jkraybill That's a good point about testing and SeeAllData. If Apex can't modify the custom metadata type records in the test setup then the test case is stuck with whatever the current records are.

    Here's another article that sheds some light on it: https://developer.salesforce.com/blogs/engineering/2015/05/how-to-use-custom-metadata-types.html?utm_source=dlvr.it&utm_medium=twitter. Biggest thing looks like you can protect some settings. I think I saw that lookup relationships are coming to custom metadata types. Right now there is no custom UI for entering or updating records - that's a huge hole.

    @jkraybill Injecting configuration dependency is my main worry as well.

    @DanielHoechst - Layoutable UI for entering and updating records is one of the big features coming out in Winter -- take a look at https://developer.salesforce.com/blogs/engineering/2015/08/custom-metadata-types-winter-16.html .

    @DanielBallinger - record-level protection of configuration (as opposed to hiding the entire type, which is both a custom settings *and* a Summer CMT feature) is another. (The third big feature is field-level control over who can edit values. By setting a field to subscriber editable, you'll be able to default the value in a package and let customers change that value if they need to.

    @AvromRoy-Faderman It's great to see the gaps being filled in the CMT functionality. I've merged your comments into your existing answer.

  • I’m the original inventor of and lead developer for custom metadata types.

    Although we have a variety of use cases in mind, custom metadata types are primarily intended to let you develop peers of Salesforce standard metadata types, such as custom fields, tabs, or workflow rules (obviously in this first release we don’t have the power required to duplicate all the functionality in these types).

    Just as you can’t perform CUD on such types in Apex today (you can’t create a new tab, modify a custom field, or delete a workflow rule in Apex), you can’t yet perform CUD on custom metadata types in Apex, short of a metadata API callout. You can help us get that feature prioritized by voting for the idea here. To see how to create tooling using Apex for a custom metadata type, you can look at Jean-Baptiste Pringuey’s sample “configurator.”

    Testing is a tricky question, which I address in a blog post I just posted. The use case you describe is definitely a legitimate one. There's been a fair bit of demand for configuration visibility to ftests. See the idea Custom Settings should be treated as a Setup Object for APEX Tests

    There’s a lot more planned for custom metadata types than custom settings on steroids. App configurations that don’t have to be re-created in every environment and that can respect managed state (so you can have some that are not deletable or mutable by subscribers) was just a starting place that filled a known need. Aaron’s second blog post gives you a taste of things to come in the near term (safe harbor applies, of course).


    Winter `16 features

    Layoutable UI for entering and updating records is one of the big features that came out in Winter -- take a look at Custom metadata types: they’re money; actually, even better!

    Record-level protection of configuration (as opposed to hiding the entire type, which is both a custom settings and a Summer CMT feature) is another.

    The third big feature is field-level control over who can edit values. By setting a field to subscriber editable, you'll be able to default the value in a package and let customers change that value if they need to.


    More recent features

    It's been a while!

    Custom Metadata types now support (as of Summer 17):

    • Picklist fields
    • Relationships to records of other custom metadata types, to SObject types (EntityDefinition), and to SObject fields (FieldDefinition)
    • Text Area (Long) fields
    • Asynchronous (but not requiring remote site settings) upsert in Apex via Metadata.MetadataOperations.enqueueDeployment()
    • Validation formulas (including traversal of relationships)

    It sounds like there are lots of good things coming to close the gap with the existing list custom settings and provide. I've voted for the linked ideas.

    Any plans to include RICH TEXT or even a LOOKUP as a field type in custom metadata? That would be useful help for us. Here is the idea to vote up. please https://sfdcfanboy.wordpress.com/2016/01/12/salesforce-ideas-custom-metadata-type-settings/

    We're considering rich text. We're definitely planning (in fact actively working) to support relationships, though their behavior will be a little different from a regular lookup field.

    I know it's been awhile, but in case you still work there :)) it would be great to allow a single-entry custom metadata types (e.g. when we have a global package setting applicable per org, the subscriber admin still has the option to add many), and it would be even more awesome to allow FlexiPages with LWC as UI for the custom metadata.

    Sorry this is so late in reply: I still work at Salesforce, although my relationship to the team that does custom metadata is a little less direct now. Anyway, I do see the value there, but note that there are a couple of ways around it, though I admit they're not super-pretty: For example, you can write your queries to ignore records that don't have your namespace, or even place a validation rule on your CMT that checks record namespace.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM