Skip to main content
New tool CRON Expression Builder — preview next run times before you schedule Apex. Open the builder →
A 3D render representing modular Salesforce Flow automation and configuration management architecture.
Flow

Salesforce Flow and Custom Metadata: A Developer's Guide

Hardcoded IDs and strings inside a Salesforce Flow break the moment you deploy to another org. Custom Metadata Types keep that configuration outside the Flow.

Vinay Vernekar · 2 min read
The short answer

Record IDs and status strings hardcoded into a Flow break the moment you deploy to another org. Move them into a Custom Metadata Type and read them with a Get Records element. Custom Metadata deploys through change sets and SFDX, and it is cached, so the lookup does not cost you a standard SOQL query.

Key takeaways Move hardcoded strings, IDs and parameters into Custom Metadata Types so the Flow stays maintainable. Custom Metadata is deployable metadata, so your Flow configuration travels through the CI/CD pipeline with the rest of your changes. CMT cuts down the constant SOQL queries against heavy configuration objects, which keeps Flow execution efficient. Changing a value in a metadata record takes seconds and needs zero changes to the Flow itself, so a minor configuration update is less likely to introduce a bug.

Why hardcoding in Flow is a risk

Building a complex Salesforce Flow, it is easy to drop IDs, record type names or status strings straight into decision nodes and assignment elements. Those "magic strings" break when you move between environments, sandbox to production, because record IDs change and configuration names drift.

Store the configuration in Custom Metadata Types

Custom Metadata Types (CMT) hold configuration data efficiently. CMT records deploy through Change Sets or DevOps pipelines (SFDX), which Custom Settings records do not, and that makes them a good fit for environment-specific configuration.

Implementation steps

  1. Create a new Custom Metadata Type, for example Flow_Configuration__mdt.
  2. Add fields for the data you change often: email addresses, user IDs, environment-specific thresholds.
  3. Fetch the metadata with a Get Records element. CMT is cached, so this is fast and does not count against your SOQL governor limits the way a standard object query does.

Example: dynamic email routing

Rather than hardcoding a support email in your Flow's Send Email action, store it in a metadata record.

  1. Create a record in Flow_Configuration__mdt named Support_Email_Config.
  2. Add a Get Records element to your Flow, with the Object set to Flow_Configuration__mdt and the filter DeveloperName Equals Support_Email_Config.
  3. Map the field value from the record variable directly into the Recipient Address field of your action.

Performance considerations

Salesforce caches Custom Metadata records at the application level, so your Flow runtime retrieves these values with minimal latency. And because CMT queries are treated differently from standard record queries, they are a good way to keep automation inside execution limits while the logic stays configuration-driven.

Originally reported by reddit.com

Newsletter

One email every Tuesday

New guides, tool updates, and the release-note changes that break things.

No spam. Unsubscribe in one click.

Salesforce Flow Fault Paths: Error Handling GuideFlow

Salesforce Flow Fault Paths: Error Handling Guide

Salesforce Flow: The Complete Guide to Declarative AutomationFlow

Salesforce Flow: The Complete Guide to Declarative Automation

Screen Flow Business Logic: Advanced WorkaroundsFlow

Screen Flow Business Logic: Advanced Workarounds

Comments

Loading comments...

Leave a Comment