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.
You’ve just spent loads of money customising Salesforce to meet your specific business needs, and now your Account Executive is presenting you with the idea of “Managed Services”. What is Salesforce Managed Services, and why do you need it if your project was built and delivered properly?
Performing a Salesforce Technical Health Analysis is an important best practice to ensure you are getting the most out of your CRM investment. Bringing your system up to speed with your evolving requirements and Salesforce’s latest features is fundamental for business success.
Some things will happen whether you prepare for them or not, so what’s the big deal if we just ignore our Release Update prep, and what is there to do, anyway?
Relying on a CRM is a fundamental business decision and intrinsic to strengthening customer relationships. Salesforce is the digital platform that portfolio companies need for objective decision-making. It gives them the advantage of always being one step ahead, even volatile markets.Learn the powerful reasons our UK-based Managing Director, Kirk Heuser, has learned about why private equity firms seek a trusted CRM, like Salesforce.
Luke Toland, a Salesforce Consultant at EMPAUA, teaches you how to Connect your Salesforce org to an external API using zero lines of code. Use declarative tools and OpenAPI specifications to describe the external API functionality, and External Services creates invocable actions within Salesforce Flow that interact with the external API source.