You can now use Custom Metadata Types to define and store your own metadata settings — and you can deploy these between orgs! Previously you had to use Custom Objects or Custom Settings, which don’t bring data over when you deploy them. Using Custom Metadata makes managing your deployments easier and lets you think about your configuration metadata in new ways. Read on for a real-life example!
In the Summer ‘15 release of Salesforce, developers and solution architects all over received a huge gift: Custom Metadata Types. Even the name sounds extravagant and technical! Isn’t it awesome?
You all say this is a thing you wanted, but why?
Custom Metadata Types are genius because they allow developers to think at a higher level of abstraction.
More developer-ese. Can you just give me an example?! No one is talking about how you’d actually use it!
OK, let’s dig into how Bigger Boat is using Custom Metadata for one of our clients.
Childhaven, an amazing organization here in Seattle, provides care for at-risk children. They do this incredibly successfully, in great part due to a detailed behavioral assessment framework that they developed. Teachers and caseworkers use these evaluations to track children’s progress and plan next steps for their care.
There are over 150 possible behavior ratings on the assessment, and as a child ages and moves through the program, different behaviors are rated.
So an infant is rated on a very different set of behaviors than a two year old or a five year old. That makes sense…
But that means we need to build a form that dynamically displays the right questions based on the child’s age, and we want to be able to validate that all the required questions for the child’s age are filled out. Uh oh. We can hard code the conditions for whether or not a field is displayed, and we can hard code validation logic, but what if the age range for a question needs to be changed?
Yeah, what if the admin wants to update the age range for a question without hiring a developer to update the code?
Right. We start running into problems.
So how do custom metadata types help?
They allow us to think at a different level of abstraction.
You keep on using that phrase…
Stick with me! In the case of these evaluations, we want to be able to track and access information about each question, such as at what age range should this question be displayed, and is it required or not. So we created a custom metadata type for Questions, with fields to store information about each Question.
But Questions are fields on the evaluation. So you have fields about fields now?
Yes, exactly! Fields about fields!
Very meta…ohhhh…
METADATA! Right! We now get to store our own custom metadata! So for each possible question on the form, we create a Form Question record to store metadata. We can store the ages where a question should start and stop appearing. We can store lengthy custom help text that defines the behavior. We can store which section of the form the question should appear on. We can even store how we want the question to be displayed, so that we can build and display custom scale rating components for yes/no radio buttons or 1-5 radio button scales, instead of just relying on standard picklists or number fields. And then our code can simply reference this metadata, which an admin can adjust without touching code!
Wait a second, couldn’t we just do this with a Custom Object? Why do we need custom metadata types? Everything you’ve said so far doesn’t need some fancy new feature. We have custom objects, we can take over the world!
You are correct! Technically. There are, however, many differences between a custom object and a metadata type. Two are really important.
First, the boring one — custom metadata type queries don’t count against your normal query limits. This isn’t a huge deal, but in really big projects it’s nice to not worry about the governor limit.
Yup, pretty boring. Nice, but boring. What’s the exciting one?
Ok, get ready. The reason we LOVE custom metadata is that it can be DEPLOYED! It’s best practice to build & test any changes in a sandbox, so on a big project there may be 3-4 sandboxes plus maybe a developer org or two floating around. Instead of having to manually re-create or import/export the records of a custom object to each org whenever they change or whenever we adjust functionality, we can just drop them in a changeset. Just like you’d add a new field or update a page layout, we’re pushing these Form Question objects around to make sure our environments stay in sync. It is both more efficient and less error-prone.
Ok, that is pretty cool.
I know!
You really like databases.
Yeah.
Interested in learning more? Read Introducing custom metadata types and How to use custom metadata types on the Salesforce Developer blog.