or, Summer ’17’s Biggest Custom Metadata Types Feature Isn’t a Custom Metadata Types Feature
We released a couple of great features for custom metadata types in Summer ’17. For one, we made long text area fields on custom metadata types generally available. For another, we now fully support validation formulas on custom metadata types. These features give you even more reason to move to custom metadata types from list custom settings—if you haven’t already.
But by far the feature that I’m most excited about is a piece of something much broader. I’m taking about a feature that we’ve probably gotten more requests for than any other feature on the roadmap for custom metadata types. You told us that you need to create and update records of custom metadata types natively in Apex, and now you can.
To make this feature happen, we teamed up with the Apex and Metadata API teams. Together we implemented a way to synchronously read and asynchronously deploy metadata. The implementation functions as if you were using the read and deploy metadata operations, but it doesn’t require a web service callout.
What this Means for Custom Metadata Types as a Way to Store App Configurations
The ability to write records in Apex was one of the last reasons why you might have continued to use list custom settings or custom objects instead of custom metadata types to store your application configurations. At this point, we strongly suggest that you develop with custom metadata types instead, except for a few edge cases. Check out this table for a comparison of all three options.
If you’re just interested in custom metadata types as a replacement for custom settings and custom objects used for app configurations, you can probably stop reading here. However, the Apex metadata API goes far beyond closing a functionality gap between custom metadata types and custom settings/objects…
Platform on the Platform: The Vision
Though they are very different features, custom metadata types and the Apex metadata API are part of the same vision, which I like to call platform on the platform. So what is it? Well, to understand that, you first need to think about the Salesforce Platform in general. We use it to develop many of our application offerings. And our partners and customers can use it to customize our applications or to build their own, essentially making our app offerings more complete. This is illustrated in the following image.
Platform on the platform is the idea that not only can you use our platform to modify or create applications, but you can use it to modify or create platform features. With it, we give you the same power that we have—your own platform. You can build your own apps on it or, if you’re an ISV, let your customers and partners use it to make your app offerings more complete.
Custom Metadata Types and Platform on the Platform
What does “your own platform” consist of? If metadata is to drive it so that admins, not just developers, can use it to build applications, it needs to
- Specify what metadata it needs.
- Include code that looks at the metadata to let partners and customers customize your app, or build their own apps, to fit their specific needs.
- Create a way for admins and developers to provide that metadata.
Take a look at these examples of what we did, and what you could do yourself.
If you already use custom metadata types, you likely already understand 1 and 2. I bet you have questions about number 3, so let’s talk about your options next.
The Apex Metadata API and Platform on the Platform
How do you provide a way for people to create the metadata your platform features need? Well, you don’t have to, because we created a couple of ways for them to do so. There’s our basic “Manage Records” in the custom metadata types setup UI. There’s the regular old Metadata API, for use with the Force.com IDE, and the command-line metadata API client, for other integrations. Admins and developers can already use these tools to create the metadata that your platform needs without your help.
But there’s a good chance you want to help them with tools better suited to the specific needs of your app. Maybe you want your app to create multiple records at once (e.g., a record of one type and related records from another). Maybe you have a cool idea for inputting values that layouts don’t adequately handle. Maybe you want to make other stuff happen after someone creates a record. Or maybe you’re an ISV and you need to create some metadata of your types when an org installs your package.
That’s where the new Apex Metadata API comes in. It significantly opens up the ways you can provide for people to create records of your custom metadata types. You can build a Visualforce page or a Lightning component with a server-side controller that does this. You can do it yourself from inside a package post-installation script. Or, you can even make a simplified API to do it.
Our first release lets you deploy metadata of not only your custom types but also of a standard Salesforce type: Layout. We started with these types because they are the most in demand. As the Apex Metadata API and metadata relationship fields expand, there will be another reason to deploy standard metadata this way. You may want to create standard metadata components and custom metadata components related to them in the same transaction. This lets you create a seamless interface for making components of standard types that are integrated with your custom platform.
Fitting It All Together
A custom metadata type is the what of platform on the platform. It’s a form you specify for the metadata that drives your platform features. What you do with the Apex Metadata API is the how. It’s a set of tools to create and edit metadata your way.
If you want to expand the types of metadata you can support this way, help us advance that goal by going to the “Apex Metadata API” Chatter group in the Success Community and letting us know what additional metadata types you want supported and why.
Author Bio
Avrom Roy-Faderman is a Principal Software Engineer at Salesforce.com. He’s the inventor of custom metadata types, and drove the architecture of the Apex metadata API.