How to leverage custom metadata types
The Salesforce platform is incredibly extensible. Customization is deeply ingrained into the experience. The AppExchange is home to a diverse ecosystem with thousands of apps, created and curated by development teams of all sizes. Once installed, these applications can be tailored to meet your specific business needs.
Customization becomes easier thanks to Custom Metadata Types! This platform feature enables customization of third-party Salesforce apps through ‘clicks-not-code.’ More importantly, these can be pushed into your production org via change sets or included directly in a managed package.
First appearing with general availability in Summer 15, Custom Metadata Types continue to mature and become more powerful with every Salesforce maintenance release. Looking ahead, the roadmap teases some very promising features and presents an exciting future for this technology.
What is metadata?
Metadata describes data. If you’ve ever defined your own custom object or custom fields, you are probably already familiar with the concept. Say you wanted to add a field to the Account object. You would need to configure properties such as its name, data type, field length and whether or not it can be left blank. This field definition is metadata.
Custom metadata types extend this concept. In fact, the interface for creating custom metadata types and custom metadata records is almost identical to that of creating custom objects and custom object records. In Apex, custom metadata types can be treated as SObjects and respond to SOQL queries the same way SObjects would.
Custom Metadata vs Custom Objects
Custom metadata records can be queried using SOQL, but the platform internally caches the metadata records and can retrieve them more quickly than it retrieves SObject records. Querying custom metadata also doesn’t count towards SOQL limits, which is good news for performance and throughput in enterprise organizations.
Custom Metadata vs Custom Settings
Custom metadata records can be packaged, which is not the case for either custom objects or custom settings. You have greater control over the visibility of custom metadata types; you can hide the custom metadata types themselves or just hide specific records. You can also control whether or not users can update record values on a field by field basis.
These are major selling points for adopting custom metadata types. Package developers often want to ship default records with their managed packages. Prior to custom metadata types, they would have spent considerable development effort writing post-install scripts to create the data. They would also have to ensure the application coped gracefully with the data not existing; either because it hasn’t yet been created or because a user deleted it.
Custom metadata records can also be pushed from sandboxes to production orgs via change sets. This allows you to follow platform best practices; testing out changes in a sandbox before migrating them via change sets into the production org.
In contrast, records for custom objects or custom settings can only be migrated manually, for example:
- Export the data somewhere and then import the data to the target org e.g. via the Salesforce Data Loader, or perhaps custom import/export solutions if the managed package provides any.
- Generate the data using a script.
- Re-enter the data manually.
However, each of these manual approaches is time consuming and prone to human error.
Custom metadata types use cases
Reference Data: Many applications utilise lists of ‘reference data,’ i.e. unchanging data that is referenced by other records.
Examples include:
- Country ISO codes (Afghanistan → AFG, Albania → ALB, Algeria → DZA etc.)
- Conversion rates (kilograms → pounds, Celsius → Fahrenheit etc.)
- Whitelists (approved managed package namespaces, approved email address domains etc.)
These values could be hard-coded into an application, but adding/changing values could only be achieved by updating the code (or via package upgrade if it’s a managed package). Hard-coding the values would also prevent the reference data lists from being re-used by other applications.
Alternatively, you could store the data as records of a Custom Setting or Custom SObject. Indeed, that’s an approach used by many developers before the introduction of custom metadata types. The problem is that the records cannot be included in a managed package, and cannot be migrated via change sets.
Configurations
The most compelling use case we’ve found so far in development is to allow generic injection code into an application. For example, Custom Metadata could be used to name an Apex class, and the application could create and execute a new instance of that class.
The application could schedule Batch Apex jobs against user-defined Apex classes. For extension packages (more info here), the application could detect and run extension-package overrides for certain Apex classes, allowing the extension package to create self-aware idiomatic behavior. With custom metadata, the named Apex classes would be installed alongside the package, without the need for post-install steps. And it would be impossible for the user to update or delete those custom metadata records and break the integration. This was simply not viable before Custom Metadata Types!
Further Reading:
Conclusions
Custom metadata types have certainly caused a stir within Certinia R&D. We continue to find new and innovative ways to leverage them to create wildly successful customer experiences.
Indeed, custom metadata types sit at the core of a number of high-profile product areas under active development. Custom metadata types have already been adopted in released versions of some of our flagship products. You can look forward to even more customisable Certinia products with smoother installations/upgrades as a direct result of Custom metadata types.
