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).

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 Code	Office	State
1 – 10	Headquarter	CA
11 – 20	New York Office	NY
21 – 30	Boston Office	MA
31 – 40	Miami Office	FL
41 – 50	Seattle Office	WA

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.

Record-Triggered

Get Records

Update 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