Flow: How To Use Custom Metadata Type

I am very excited about this case I received. I know custom metadata type and custom setting for a long time, but I have never had the opportunity to use them. In this article, I will summarize the difference between custom setting, custom metadata type, and custom object. I will also provide a Flow use case example at the end, so let’s dive in!

* Big thanks to Korede for sending in the case!

Custom Metadata Type v.s. Custom Object

Custom metadata type is just like a custom object – you can create custom fields and records! This is the key point that helps me conceptualize the custom metadata type.

Then to understand the actual difference, I find this screenshot very helpful. You can check out the full Salesforce webinar if you are interested. (It is a very good one by Jennifer Lee with a business example).

Source: Advanced Automation with Flows and Custom Metadata Types Webinar

But if you want a quicker overview, here is my summary of the key pros and cons of the custom metadata type (CMDT):

Pros – What CMDT can do but Custom Object can’t:

1. CMDT records are metadata which is deployable through change sets

2. You can reference CMDT records in formulas

3. There is no limit on SOQL query*, and the records can be retrieved faster

* The governor limit still applies when using CMDT in Flow.

Cons – What CMDT can’t do but Custom Object can:

1. You can’t create custom tabs for CMDT

2. You can’t create reports for CMDT in Salesforce

3. You can’t create CMDT records in Flow unless you use custom components.

4. It is hard to mass update CMDT records (Need CLI commands)

Custom Metadata Type v.s. Custom Setting

Now we have the basic idea of what custom metadata type is, we can discuss what custom setting is. They are very similar, but custom metadata type has some more advanced features than custom setting. The biggest difference is that the records of custom setting are also data, which is not deployable.

Most of the time you would want to choose CMDT except for these two following scenarios:

1. Hierarchies – When you need to personalize the field values based on user or profile

2. Web service credentials – When you don’t need to deploy the test credentials

(In the reference article, it says you should use custom setting if you need to modify the records with code. However this is now achievable for CMDT too)

In short, unless you want to customize the values for different users, you can always choose custom metadata type instead.

Let’s Check Out A Real Example!

Lulu Mobile has 5 different offices. Each office takes care of different products which are identified by numbers 1 – 50. The table below suggests how their responsibility:

Product CodeOfficeState
1 – 10HeadquarterCA
11 – 20New York OfficeNY
21 – 30Boston OfficeMA
31 – 40Miami OfficeFL
41 – 50Seattle OfficeWA

They use the standard Opportunity object and have a field called “Product Code”. Depending on the code, they want to auto-populate two other fields – “Office” and “State”.

We will use a Record-Triggered Flow with the Before trigger to achieve this since we are updating the same record.

Since this table applies to the whole organization and the users might reference it in other objects, it is not recommended to hardcode them in the Flow.

These offices are not likely to change and do not need heavy maintenance, so we will create the table as a Custom Metadata Type. This way we can deploy the actual records from sandbox to production.

* Assumption here is you can only enter 1 – 50 for the Product Code on Opportunity and the value won’t be cleaned up.

Flow Chart (deactivate last login date)

Steps (deactivate last login date)

Record-TriggeredGet RecordsUpdate Records

Does the solution solve your problem? If not, write us what your problem is and we will build the flow for you!

Official Salesforce Help Article On Flow

Notify of

Newest Most Voted
Inline Feedbacks
View all comments

Hi Melody. How would you use CMT’s for record types of the same object? Would you create one CMT, and then add fields for each of the record types? Secondly, if the field references ultimately the record Id of the RecordType object, and let’s say the Id’s are different between a sandbox and production, when the CMT is transferred via a change set, referencing an Id that is different between the instances wouldn’t create an issue? (I thought that was one advantage of CMT’s, that no matter the Id of the record being referenced, these could be deployed across org’s without requiring updating of the CMT). Thanks!


Hi, Melody. Is there a way to avoid hard coding record type or user id inside the “start” part of the record triggered flow in sandbox environment?
P.s.thank you for this wonderful documentation on CMDT!


Hi Melody, what if i put product code 12 in opportunity update. and why are we sorting the CMDT records using product code value in ascending?