With the general availability of custom metadata types, “someday” has arrived.

In this post, Salesforce MVP Andrew Fawcett wrote, “What would be ideal at this stage is a way for us to create custom metadata on the platform, maybe one day….”

I am thrilled to announce that with the Summer ‘15 release, that day has arrived.

Until now, the Salesforce developer community could only create metadata of the types provided by Salesforce. Whether adding custom fields to the account object, creating a custom object, or developing an Apex class, you could only configure your app in ways that Salesforce provided out of the box.

Generally available in Summer ’15, custom metadata types give you the ability to do something that was previously reserved only for Salesforce employees: create your own metadata types.

Why on Earth would you want to do that? Application configurations are a key reason.

Developing app configurations today can take one or two engineering-years and put a 20% tax on ongoing development. With custom metadata types, the upfront work can be reduced to weeks and the updates to configuration tools to hours.

The records of custom metadata types are metadata

Custom metadata types are meta metadata. That’s right, they are twice as “meta!” The records of a custom metadata type are themselves metadata, not data.

This means that, unlike custom objects or custom settings records, the records of custom metadata types can be deployed from a sandbox with change sets or packaged in managed packages.

When apps with custom objects and custom settings are deployed, the metadata of those objects (the header) get deployed, but the records are left behind.

If these data are just sample data, such as invoices in an invoice custom object, this behavior makes sense.

Build your app configurations with custom metadata types

However, if these records are app configurations, this behavior is bad news. App configurations are part of your app and should travel with it.

Until now, Salesforce customers and partners have commonly used list custom settings and custom objects to store configuration data and have had to work around the inability to package or deploy those records with your app. Now app configuration records can be packaged and deployed as easily as any other custom metadata in your app, like custom fields you may have added to the Account object.

Configuration use case

Here is an example of an app configuration: Let’s say I want to integrate my org with a bunch of banks or payment gateways. (Fonteva.io demonstrated this using custom metadata types at Dreamforce 2014.) I build several tables to contain information about the financial institutions’ API endpoint definitions, credentials, nouns and verbs of the API, and mappings to indicate where data that come from the API or are sent to the API are stored in Salesforce.

The records of those tables define the actual integrations – one record per table for each API integration.

If I create those tables with custom objects or custom settings, I can deploy only the headers from sandbox to production. An ISV can package only the headers for installation in an org. The records have to be transferred some other way. All I can deploy is a configuration framework, void of any actual app configurations.

But if I create the tables using custom metadata types, my entire set of configurations – both the definitions and records – can be deployed. How awesome is that!?!

Enterprises ease their compliance headaches

If your use of configuration objects is relatively limited (few objects and/or few records in those objects), and if you don’t create or update configurations often, building app configurations with custom settings or custom objects might be a reasonable strategy.

However, a typical enterprise using Force.com has tens or hundreds of custom objects or list custom settings acting as configuration objects. Every time a record is created or updated in a developer org, it then has to be moved to various other orgs. Often, it goes to integration testing, then user acceptance testing, then is deployed to production. And of course, it could go to multiple production orgs.

In every step of this process, developers or administrators must move those records. Some enterprises script the migration of their app configurations using a combination of the metadata and data APIs. While the API operations can be sequenced, they are disjoint and can’t be combined into a single deployment transaction, complicating the migration of application configurations. In addition, these scripts can be expensive to develop, test, and update.

As a result, many enterprises rely on manual processes, such as using data loader to move records or even opening two browser windows and copy/pasting records. And this isn’t a one-and-done process. It has to be done at each step of the software development lifecycle.

This process is expensive, error-prone, and most importantly, a huge headache for compliance. Manual processes are the archenemy of compliance.

Partners save years of development

ISVs have similar challenges, but they manifest in a different way. For partners, compliance isn’t the concern so much as application lifecycle management. Unless an ISV engages the customer in a professional services contract, you don’t have the ability to load and move records into a customer’s org. And even if you do have that access, that isn’t a very scalable model.

To address this problem ISVs typically write sophisticated deployment tools. This process takes many months or even years. In addition, ongoing maintenance of these tools is expensive. Anytime a new feature is created that impacts the app’s configuration, the deployment tools need to be updated and retested.

Custom metadata types free you to build apps, not tooling

Custom metadata types automate the software development lifecycle and application management lifecycle of application configurations for both enterprises and ISV partners. Because the records are metadata rather than data, they leverage all the tools Force.com already has for managing, packaging and deploying metadata. Now you can spend your time developing your app rather than your tooling!

Rethink how you build app configurations

In light of this new ability to create your own metadata types to hold application configurations, how would you rethink the architecture of your applications? What list custom settings could you replace? How many custom objects are you using to store not org data, but your application configuration data?

As you begin to imagine how your application development and management could be transformed by building application configurations from metadata rather than data, tune in next week. I will discuss the specific features in the Summer ’15 release of custom metadata types, the use cases for which they are most suited, and our plans to extend the powerful functionality that this new application configuration engine provides.