Here are some "advantages" vs using a Custom Object:
Can be Deployed
Can use Field Definition or Entity Particle to create references to Custom Object Metadata
Retrieve doesn't cost against SOQL limits (unless it contains long text)
Can be referenced in formula fields
Unit Testing isn't too bad as well as the code is well composed. Because they ...
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 ...
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 ...
The custom settings metadata can be retrieved or deployed just like any other metadata.
All you need is name of the custom setting
If you are working in orgs that cannot have source tracking enabled
sfdx force:source:retrieve -m CustomObject:<Customsettingname__c>
If you are using source tracked orgs use
If you want data within ...
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 ...
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 ...
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 ...
Your map is most likely reaching the lightning component. Did you check the console.log output in the browser ? Please put the output here for more clarity. If all is well, you should be able to see the Map ...
The platform-native functionality that is generally preferred for storing named lists of fields and consuming them elsewhere on the platform is Field Sets.
The nice thing about Field Sets is that they come with a built-in user interface for maintenance, and their content is very easy to access through the Describe API.
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 ...