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 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.)
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.
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.
In this post, we go over an edge case that exemplifies why API names in Salesforce matter and what can happen if they are not properly used. Hint: it can easily block your deployments.
Still entering manual notes after phone calls? Our partner Aircall offers the best solution for cloud telephony with Salesforce. We can advise you on the best setup and strategy. Want to know more? Read this article and start your free trial and reach out to us for more support.
You may have heard about the Log4j2 vulnerability that has been resolved recently for the Salesforce products. To better understand the severity of this issue, It is suggested that this vulnerability has impacted almost 1 million exploits.
According to Salesforce, MFA is going to take effect on February 1, 2022. It will be required for all single-sign-on SSO logins and logins through the user interface, and you can turn it on directly in your Salesforce products or use your SSO provider’s MFA service. Read more here.
Salesforce Functions are code you can run on demand which can be useful for resource intensive processing and automation tasks which you can hand over to functions which can offer an alternative to using Heroku or additional middleware.