The Salesforce Developer Community could only produce metadata for the objects offered by Salesforce prior to the release in the summer of 2015. One could only configure applications in methods that Salesforce offers out of the box, whether adding additional fields to one of the standard objects, making an entirely new custom object, or designing an Apex class.

Administrators and developers may now define their own configuration and application metadata, deploy it, and then update it as necessary inside the custom metadata types thanks to the introduction of custom metadata types.

Salesforce advises using this functionality for the following use cases:

  • Mappings: Create associations between various objects using mappings, such as custom information types that place cities, states, or provinces in certain geographic areas of a nation.
  • Business Rules: Integrate configuration data with tailored features. To route payments to the right endpoint, use custom information types and some Apex code.
  • Master Data: A custom metadata type that specifies unique fees, such as duties and VAT rates, can be created using master data. Subscriber orgs can make use of the master data if this type is included in an extension package.
  • Whitelists: Control lists, such as those for pre-approved vendors and funders.
  • Secrets: Store data (such as API keys) in a package’s protected custom metadata types.


Steps for Creating Custom Metadata Type

Make sure you have the proper permissions before beginning your quest to develop a custom metadata type. In reality, admins should be the ones creating these entries, which is why programmatic access requires either the “Customize Application” or “Author Apex” rights.

Additionally, it is possible and, in certain cases, necessary for other users to have access to examine these records. It is simple to handle this with profiles or, even better, permission settings for each unique sort of custom metadata.

Create A Unique Metadata Type

When you choose to use custom metadata instead of, say, defining many fields on various objects to store specific information, declaratively constructing becomes a piece of cake.

You will be asked to enter the name, description, and choose the visibility options for the new custom metadata type after selecting “Custom Metadata Types” and clicking the “New Custom Metadata Type” button.


Create Custom Fields

The custom metadata type was easy to create, but depending on your use case, creating the fields could be challenging—just like with any other Salesforce object you’ve previously worked with.

I created a Name, Email, Phone  custom fields, however in this case. As you can see, unlike any other object, the custom metadata type has the “__mdt” suffix instead of the “__c” suffix that the custom field has.

The parallels between this and a regular or custom Salesforce item continue. Additionally, you can design page layouts, validation rules, and list views. I modified the layout after adding the new Country Code field and made the field mandatory.

While a master-detail relationship field is not a possibility, the Metadata Relationship field type is. You can also build some of the field kinds you could on a custom object, such as picklist, number, or even text. Through a connection to another custom metadata type or entity definition, this can open up a to one of other opportunities.

Add or Edit Custom Metadata Records Declaratively

Now that you know what the ‘thing’ is made of, let’s start making some recordings! You must once more look for “Custom Metadata Types” under Setup.

This time, however, because the custom metadata type already exists, select “Manage Records” next to the one whose records you want to change.

The record’s level of protection is indicated by the “Protected Component” checkbox. Code you write, code in an unmanaged package, and code in the same managed package as either the protected record or its custom metadata type have access to protected records only if they are in the same namespace as the record or the custom metadata type they are associated with. Click “Save” when you’re finished.


Mass Insert or Update Custom Metadata

Given that Setup already includes a declarative method for performing simultaneous creation and update of many custom metadata fields, this task is undoubtedly challenging. As you may imagine, modifying or creating numerous records manually can quickly become a tiresome chore.

Despite being around for a while, the Custom Metadata Loader is still an extremely quick way to import numerous records from a CSV file into your Salesforce org.
This is an admin-friendly method since bespoke metadata type records can be created—or, why not, updated—and access to this feature is restricted by a permission set once it has been implemented.
Administrators can quickly update dozens of records in their sandbox.

The Custom Metadata Loader and instructions are available here.

Since the summer of 2020, CLI commands have generally been available to manipulate records of the custom metadata type, greatly simplifying the process for developers to add new records or fields. A CSV file can also be used to produce records directly, thus there is no need to import them until a small number of new records are required. Check out all of the commands and examples here.

Deploy Custom Metadata Types

Custom information types have the benefit of being completely deployable and packageable, which is one of their advantages. If admins still frequently transfer components across environments, you can quickly deploy them with change sets. Alternatively, you may use the Metadata API to directly fetch and deploy them to the chosen org.

Let’s explore the newly created records using the brand-new Code Builder to see how they appear as XML files.

Note: You can modify the files as you would in VSCode if necessary, save your modifications, or, when appropriate, overwrite them with the metadata from your organisation.


Scalability would be the word I would use to describe how custom metadata types aid. This Salesforce functionality can help you save time and customise process behaviour declaratively while ensuring governance over important data points, which is especially helpful in complex organisations when delivering robust implementations (whether it be as a package or as part of a custom solution built for a specific business need).

For what purposes are you going to use custom metadata types? Please leave your opinions in the section below.