Salesforce Custom Metadata - usage and advantages

Custom metadata types in Salesforce is a great and powerful feature provided to developers of the platform. Till this feature was provided, developers could only create and modify metadata for the types provided by Salesforce. They could add new objects, new apex classes etc. With custom metadata, a developer can define a new metadata type itself. After defining a metadata type, the developer can now add metadata records for this new type.

Whats the biggest advantage? well since this configuration is considered metadata, it is available via the Metadata API. So it can be migrated between environments using migration tools like ANT. Let me explain below with an example -

In our project, we were configuring ability to calculate SLA on a case based on when the case is received into the Queue. That is if the case arrived after a particular time (say 4 PM), it would be considered as arrived next day and SLA should be calculated only from the next day. Now, each queue in the system had a different cutoff time based on that team's requirements. This could be achieved in different ways however what i want to focus on is how we stored this cutoff time information for different queues. This information can be considered configuration data that needs to be present in each sandbox and production environment.

Option 1: Custom Object
We could create a custom object that stored records with the Queue name and its corresponding cutoff time in each record. While configuring this object and using it in say Apex code would have been easy, the issue would normally be with migrating the data between sandboxes and production.
Hypothetically if we had 50 queues, we would have 50 records in this custom object. Now to move this configuration to Production, there would be two steps -

1. Migrate the custom object, fields etc to Production via changesets or ANT migration tool
2. Migrate the 50 records using data loader or manually

Using custom metadata, we can avoid this second manual step. Remember this second step needs to be done for each sandbox environment you have between the developer sandbox and production.

Option 2: Custom metadata

Instead we created a custom metadata type called "SLA Cutoff Setting" and used it to capture the cutoff time configuration records using this metadata type. Now to migrate it to another environment, we can simply use ANT or change sets. Since the records are considered metadata, they can be migrated just like any other metadata. Using change sets, both the new metadata type and its 50 metadata records can be transferred to the new environment.

You must see the advantage of this especially if you have multiple such configuration data in different custom objects or custom settings in your Org!

In my next post, i will share details of creating the custom metadata type and then migrating it using the Force Migration tool (ANT based).
Link to the next post - Salesforce Custom Metadata - creation and migration