Custom Metadata vs. Custom Objects in Managed Package

I've always seen them as an alternative to Custom Settings as much as an alternative to Custom Objects.

However, one use case that stands out where they were really useful was in configuring mappings in a point-to-point integration inbound to Salesforce where they essentially acted as the middleware.

We could create mappings of values from the source system to values in specified fields on specified SObjects in SFDC, and kept this to be a declarative exercise. Again, nothing that couldn't be done in JSON, but this was a Professional Services engagement where the customer was extremely keen to avoid code-heavy solutions (and they'd have classed JSON manipulation as that) due to having no available in-house resources for that.

Robert - in response to your point about Custom Metadata being hard to set up in unit tests

I use the selector pattern to query all sobjects, including Custom Metadata, then, use mocking via dependency injection to return the results to the testmethod. This decouples the testmethod from any live custom metadata (and thus achieves test isolation). Here is a small fragment

Standard fflib Selector and apexmocks pattern follows; assumes an Application class as per fflib pattern.

Since you can't construct Custom Metadata label/developername, I resort to the JSON deserialize approach. Here, I'm using the SObject Fabricator repo but there are other ways to do this including maps, json strings, or other libraries. Once you go the dependency injection route to unit tests, it is inevitable you will need at some point to have to construct sobjects that aren't supported by new TheSObject(..). I liked SObject Fabricator for its expressiveness.

fflib_ApexMocks mocks = new fflib_ApexMocks();
// Given mockSelector results
MyCustomMetadata__mdt[] mockMdts = new List<MyCustomMetadata__mdt> {
                (MyCustomMetadata__mdt) new sfab_FabricatedSObject (MyCustomMetadata__mdt.class) // [
                        .setField(MyCustomMetadata__mdt.Label,'foo')
                        .setField(MyCustomMetadata__mdt.SomeField__c,true)                          
                        .toSObject(),
                (MyCustomMetadata__mdt) new sfab_FabricatedSObject (MyCustomMetadata__mdt.class)    // [1] not troubleshooter
                        .setField(MyCustomMetadata__mdt.Label,'bar')
                        .setField(MyCustomMetadata__mdt.SomeField__c,false)
                        .toSObject()
        };

// Given mock selector(s)
MyCustomMetadatasSelector mockMdtsSelector = (MyCustomMetadatasSelector) mocks.mock(MyCustomMetadatasSelector.class);
mocks.startStubbing();
mocks.when(mockMdtsSelector.sObjectType()).thenReturn(MyCustomMetadata__mdt.SObjectType);
mocks.when(mockMdtsSelector.selectByLabel(new Set<String>{'foo'}))
            .thenReturn(new List< MyCustomMetadata__mdt> {mockMdts[0]});
mocks.when(mockMdtsSelector.selectByLabel(new Set<String>{'bar'}))
            .thenReturn(new List<MyCustomMetadata__mdt> {mockMdts[1]});
mocks.stopStubbing();
// Given mocks injected
Application.Selector.setMock(mockCrsdToDescriptionsSelector);

// when code-under-test invoked
Test.startTest();
new MyClass().doStuff();
Test.stopTest();

// Then verify
.. asserts and/or mocks.verify

Note that if the selector method is called with a set containing only foo, the first mocked custom metadata is retrieved by the dependency-injected selector. And, if called with a set containing bar, the second mocked custom metadata is retrieved.

Since you can't construct Custom Metadata label/developername, I resort to the JSON deserialize approach. Here, I'm using the SObject Fabricator repo but there are other ways to do this including maps, json strings, or other libraries. Once you go the dependency injection route to unit tests, it is inevitable you will need at some point to have to construct sobjects that aren't supported by new TheSObject(..). I liked SObject Fabricator for its expressiveness.

I know you use your own testobject fabricator so adapt as necessary.

Some benefits not listed but I like are:

• Page Layouts (custom settings can get quite messy for customers given we don't control the layout). With metadata types, we can publish layouts.
• An indirect one seems to be for the customers: they can manage their configuration and migrate through environment more easily than custom settings.
  • This can make their lives much easier because some rely on manual steps to configure environments - including production.
• Allow reference to object and field in a controlled way.
  • This usually looks like a string in a custom setting. Using "Metadata Relationship" with custom metadata types this is tied to real object and fields while editing, visualizing.

I still agree that a lot should be improved and not being able to fully replace hierarchical custom settings also make them a little less appealing. Plus, unit tests experience with them still more painful.

We've implemented them and it was one of the biggest disappointments as an ISV, here's why:

• Doesn't support every object (surprise, Users don't work!)
• Creating via code is absolute pain as it's either async or metadata deploy - both means thousands of lines of code (but only second one is reliable)
• Impossible to relate to an SObject (kinda makes sense since it's deployable, but opposite should be possible)
• Doesn't have a createdbyid, lastmodifieddate, etc

There was also some obscure SOQL limitation that I can't remember at the moment.

Basically it's only upside (deployable, wow) hardly justifies all the downsides.

A reason I haven't seen articulated yet applies specifically to the managed package context:

Packaged, protected Custom Metadata Types are an ideal solution for secret storage in a managed package context. While Protected Custom Objects and Protected Custom Settings can also offer secret storage, only Custom Metadata Types allow those secrets to be packaged and deployed, and protected from everything outside the boundary of packaged Apex.

The big reason for me to use Custom Metadata is the logical separation between Custom Metadata and Custom Objects. In my head they serve a different purpose and that helps me better organize things in my org. I would store any configurations for my applications in Custom Metadata rather than Custom Objects. The way I see it Custom Objects should retain data about records in the org.

Additionally as NSjonas pointed out CM doesn't count against the governor limits in the org. They can be refreshed to sandboxes and are cached data which would provide better performance.