Background
We’re seeing more and more configurable applications built on the Salesforce platform. Product managers are wanting any packaged code to be configurable by the installer, especially for OEM applications. Naturally, Salesforce followed with the an extension of the platform that provides us with the tools to do more of this without having to hack our way through it.
Why do you care?
- No more pushing data updates out to all of your customers via install scripts prone to failure – your config data is now packageable
- Features of custom metadata types will match or beat all of the best features of custom settings
- You’ll be able to have a mix of managed and unmanaged, protected, and public records
- Your application can now be completely, dynamically data-driven
The Future is Bright (Safe Harbor)
Fortunately, Salesforce is investing to make custom metadata types the standard for developing configurable applications.
- A user interface is coming soon. We developed a UI in a couple of weeks to view, create, and delete types as well as records
- Hierarchical relationships between records are coming soon.
- Aaron Slettehaugh and Avrom Roy-Faderman at Salesforce are working hard to include any features that may benefit YOU. Join the Chatter group and suggest your ideas.
Implementation
We started building an application which uses workflow across multi-orgs around the time the pilot version of custom metadata types were released. After evaluating whether to use custom settings or custom objects to hold the definitions of these configurable workflow processes, we ultimately chose custom objects for the ability to easily have a UI for configuration and the ability to view hierarchical relationships without having to build custom pages. We thought we’d have to push changes to the workflow definitions out via post-install script with the “metadata” stored in static resources. Along comes custom metadata types. A light bulb went off. We can use these for everything we want to control by config data: workflow definitions, form definitions, api endpoints and so on. Step 1: Create your __mdt.object xml files. This is essentially the custom object your metadata records will be created from. Step 2: Create your __md xml files. These are the records you’ll query in SOQL to tell you what to do dynamically within your application defined however you want. Don’t worry, SOQL is unlimited against custom metadata records. Step 3: Package and deploy. Step 4: Anytime you want to change your config, just update and push upgrade.
We’re Here To Help
After working with this feature throughout the pilot phase and now having made the conversion to the Summer ’15 version, we’ve seen what works really well for custom metadata types. We’ve also tried some things that didn’t work so well. We can provide a review of where this can be used in your app, help you implement a custom UI for maintenance, or just make sure you don’t make the same mistakes we did.
