How to leverage Custom Metadata Types in Salesforce

‍

Hello, my name is Atlas, I’m a Salesforce Developer here at EMPAUA and a moderator at SFXD. As a self-taught-admin-turned-developer, my mission is to share what I have learned over the years, from my experience and from some of the best people in the ecosystem. You can find my previous interviews and articles at SalesforceBen too.

It’s metadata all the way down (not really)

It’s no secret that custom metadata types (CMDT) has been around for a while,  they allow us to create custom metadata and its relationships. This allows key configuration settings that can be deployed and can be changed by any user who has access on the fly. Salesforce uses the same concepts that allow for metadata to be created and configured during execution, in fact, you are creating metadata in your Salesforce org whenever you are creating a new object or adding a field.When it was first introduced, custom metadata types were only accessible through a Metadata API, so it wasn’t accessible to most users.

Now they can be deployed and configured through your setup tab similar to most metadata in your org. This feature is key for being able to upgrade your apps with different configuration files. Think of ISVs managing hundreds of customers’ orgs with different app configurations, I’m sure it helps them with their day-to-day business. Luckily, I know someone who uses them as an ISV. Here’s what Mike Tetlow, CTO of Taskray has to say about them:"As a Salesforce ISV, TaskRay uses Custom Metadata Types to configure the application and enjoy the benefits of the CMDT being deployable between environments. One use case for us involves our Customer Onboarding Score."

"This is a formula that gives each customer onboarding a project a "Score" to measure the overall success of the project. Using Custom Metadata Types, we can give our customers the ability to customize the formula the score uses.""This gives our customers the ability to tweak our core scoring functionality to meet their specific business needs.

"As an admin or developer, you can utilize custom metadata types to your advantage the same way. You can create lookups, as in relationships with custom metadata types with each other, business rules for routing endpoints with Apex as an example. You can store master data, a default setting to be reached from everywhere that has access to the package. Not only that, but you can also store sensitive credential information in a protected custom metadata type. (However, custom metadata types do not support shield platform encryption for fields.)

What about custom settings?

You might have heard them also before, but you can consider using custom settings to store configuration values for your application. However, a key difference is that custom metadata types can be deployed with their values to your package, thus allowing you to store information at a faster scale during your deployments.

Let's review an example here:

Think of deploying them with many fields with significant values, this would signal there’s probably a better way to store them - for example, a custom object you can use to load data. Does this mean we should always use custom metadata types? The answer to everything is not 42, but “it depends on”. It really does: custom settings can be configured to run with different values for users. So, I would probably choose to use a custom setting in an org with sharing architecture configured extensively by user-profiles and roles and therefore not many fields are present in the setting where we are storing the information.

There are also some limits to consider when it comes to custom metadata types. For example, SOQL query limit for flows counts towards Apex governor limits but does not in regular Apex transactions. There’s also a limit of 15 on how many you can reference in a formula inside the process builder. Custom settings also support more fields compared to custom metadata types (300 vs. 100).

Standard fields like Name and Namespace are not included in this limit, but custom ones are.To summarize, while custom settings do have their use cases, custom metadata types are deployable with their values, and they can also be refreshed to keep them up to date with sandboxes. They also have more fields supported than custom settings, and you can create relationships between them making them more versatile and from my experience, preferred more often by developers and ISVs.

Find my previous interviews and articles at SalesforceBen and connect with me on LinkedIn and Twitter. Thanks for reading!