When building automation in Salesforce, you quickly run into situations where you need values that apply across multiple processes – think prices, percentages, email addresses or API endpoints. You could hardcode these in your Flow or Apex, but that makes maintenance difficult. Every change requires a new deployment or Flow modification.
Custom Metadata Types (CMDT) offer a practical solution: you store configuration data as metadata instead of operational data. This means you can change values without modifying code, and your settings automatically travel between sandbox and production. In this article, we explain what Custom Metadata is, when to use it, and provide practical examples.
What is Custom Metadata?
Custom Metadata Types are metadata – not operational data like Accounts or Opportunities. That sounds abstract, but the difference is crucial: metadata describes how your system works, while data describes what happens in your system.
Advantages of Custom Metadata
- ✓Included in deployments
Custom Metadata records automatically travel with change sets, packages and deployments – just like custom fields or page layouts.
- ✓Consistent across environments
No manual transfer of configuration. What you build in sandbox works the same in production.
- ✓No hardcoding in Flow or Apex
Your logic stays generic. Values live in metadata records, not in the code.
- ✓Manageable by admins
An administrator can adjust Custom Metadata records without developer skills or deployment.
When do you use Custom Metadata?
Custom Metadata is meant for configuration data or rules that rarely change but are crucial for your processes. Think rates, thresholds, endpoints, sender details or calculation parameters. Below are four fictional examples showing when Custom Metadata is genuinely valuable.
Use case 1 – Pricing logic for subscriptions
A fictional software company offers various subscriptions. Prices depend on duration and number of users. Instead of hardcoding these prices in Apex or Flow, they're stored in Custom Metadata.
| Name | Duration (months) | Users | Price/month |
|---|---|---|---|
| Starter_12 | 12 | 1–5 | €49 |
| Starter_24 | 24 | 1–5 | €45 |
| Business_12 | 12 | 6–20 | €89 |
How does it work? A Flow retrieves this metadata based on duration and number of users, calculates the price and fills it in on the Opportunity. When prices change, you only adjust the metadata records – the Flow remains unchanged.
Use case 2 – Regional surcharges
A fictional courier service charges a surcharge per region on the order amount. These surcharges are stored in Custom Metadata.
| Region | Surcharge (%) |
|---|---|
| Randstad | 8 |
| Noord | 5 |
| Zuid | 6 |
How does it work? A Flow looks at the customer's region, retrieves the correct surcharge from Custom Metadata and calculates the total amount. When surcharges change, you only adjust the metadata.
Use case 3 – Email senders per brand
A fictional organization has multiple brands, each with its own sender identity. Custom Metadata ensures flows automatically select the correct sender.
| Brand | Sender name | Email address |
|---|---|---|
| GreenTech | GreenTech Team | info@greentech.nl |
| SolarNext | SolarNext Support | support@solarnext.nl |
How does it work? A Flow looks at the customer's brand, retrieves the correct sender from Custom Metadata and uses it in the email action. Adding a new brand? Just create a new metadata record.
Use case 4 – API settings per environment
A fictional integration calls an external system. The API URL and key differ per environment. With Custom Metadata, you don't need to adjust your code or Flow per environment.
| Environment | API Base URL | API Key |
|---|---|---|
| Test | https://api-test.ordersystem.nl | test123 |
| Productie | https://api.ordersystem.nl | live987 |
How does it work? Your Apex class or Flow detects the environment (for example via a Named Credential or organization ID), retrieves the correct metadata record and uses that URL and key. Each environment has its own metadata records – no manual adjustments needed.
Why not a Custom Object?
Many people ask: why not use a Custom Object? The answer lies in the difference between operational data and configuration.
| Usage | Choose |
|---|---|
| Operational data (Accounts, Orders, Transactions) | Custom Object |
| Configurable logic / configuration | Custom Metadata |
| Temporary or user-specific data | Custom Settings |
Note: Custom Metadata automatically travels with deployments. Custom Object data must be manually transferred between environments (via data import/export or API). For configuration, that's inconvenient.
Where can you use Custom Metadata?
In Flows via Get Records
Since Summer '20 you can fully query Custom Metadata with the Get Records element. You can filter on fields and use the values in your Flow logic.
In Apex
Use to retrieve all records, or query with SOQL: MyType__mdt.getAll()
In Validation Rules
You can use Custom Metadata to define dynamic exceptions or thresholds in validation rules.
In formulas or record types
Use metadata to determine default values or conditions without hardcoding.
Fictional practical example – Energy company
A fictional energy company offers gas, electricity and hydrogen. Each energy type has its own CO₂ factor used to calculate emissions per quote. These factors change annually based on new legislation.
Step-by-step breakdown
Create Custom Metadata Type
Energy_Factor__mdt with fields: Energietype__c (Text), CO2_Factor__c (Number).
Fill in metadata records
Add records for each energy type:
- • Gas: 1.8 kg CO₂/m³
- • Electricity: 0.4 kg CO₂/kWh
- • Hydrogen: 0.0 kg CO₂/kg
Build Flow for quote
The Flow retrieves the correct metadata record based on the chosen energy type and uses the CO₂ factor to calculate total emissions.
Change factor in metadata
When the CO₂ factor changes, you only adjust the metadata record. No redeployment, no Flow change – it works immediately.
Advantage: You keep one generic Flow. All energy-specific values are stored in Custom Metadata and manageable by admins.
Tips from CRM Force
- ✓Logic you want to centralize
- ✓Values you need across environments
- ✓Sharing between Flow and Apex
- ✓Configuration that rarely changes but is crucial
- ✗Customer data or transactions
- ✗Data users change daily
- ✗Temporary campaigns or seasonal data
- ✗Data with complex relationships or large volumes