Flow with Metadata Type

In today’s fast‑paced world, businesses need the flexibility to modify processes on priority without waiting weeks for code releases. Salesforce Flows have revolutionized this by authorizing admins to automate critical processes without writing a single line of Apex. But we need updates when our business rules themselves change frequently. Custom Metadata Types will play a powerful, declarative way to store configuration data that Flows can read at runtime. In this blog, we will go through a real‑world scenario where we use a Custom Metadata Type with a Record Triggered Flow to automatically set a Case’s standard Priority based on its standard Origin. No Apex, no extra fields needed just Salesforce’s best‑practice, metadata type driven design.

Understanding the Business Requirement

Imagine our support organization handles Cases coming in via multiple channels: Email, Phone, Web. Depending on the channel, the ‘Priority’ often varies. For example:

• Phone requests might need High priority because they indicate a live conversation.
• Email cases could be Medium, giving support teams some breathing room to triage.
• Web submissions may be Low, as they’re typically non‑urgent feedback.

As our company grows, these mappings may increase. Possibly we will decide Email becomes High for VIP customers or add a new channel like “Mobile App”. Hard coding this mapping in Apex or embedding it directly in Flow formulas makes maintenance painful and might lead to manual errors. Each change will require a developer’s help, a sandbox deployment and a release window. We need a more flexible, clicks and not code approach.

Post implementing the requirement in Salesforce our flow will looks like:

Use Of Custom Metadata Types

Custom Metadata Types are like custom objects but designed specifically for configuration. They will be deployable via change sets, copado,etc. or packages and can be edited directly in production by admins (when granted the right permissions). Main reasons as below:

• Read only at runtime: Flows can query them without consuming SOQL limits.
• Safe deployments: Changeset deployments of metadata type records don’t require code reviews or tests.
• Version control‑friendly: Easily packaged and tracked in our source control system.
• Declarative: No Apex triggers, no test classes everything will be in clicks.
  

By storing Origin → Priority mappings in metadata, business users can tweak values in minutes. The Flow simply reads the latest metadata record and applies it to each new Case.

Designing the Custom Metadata Type

We will now start by building our “Case Origin Priority” metadata type:

1. Define the Metadata Type
   
   • In Setup, navigate to Custom Metadata Types and click New Custom Metadata Type.
   • Label: Case Origin Priority
   • Object Name (API): Case_Origin_Priority
   • Description: Maps Case Origin values to Priority picklist values.
   • Save.

1. Add Metadata Fields
   
   • Case Origin (Picklist):
     • Values must be the same as our Case Origin picklist (Email, Phone, Web etc.).
     • Mark as Required so each record has a valid key.
       
   • Priority To Set (Picklist):
     • Values must be the same as the standard Priority picklist (High, Medium, Low).
     • Make required Enabled .

1. Create Records
   
   • Click Manage Records next to the metadata type.
   • Click New and enter a Label for example “Phone → High”, select Case Origin = Phone, Priority To Set = High.
   • Repeat for Email → Medium, Web → Low, Chat → High and so on.

By the end of this step, we have a small “lookup table” living in Salesforce metadata. Admins can edit, add or remove mappings at any time, without touching any Flow or code.

Building the Record‑Triggered Flow

With metadata in place, our Flow will run before save on Case creation, query the appropriate metadata record, and update the Case’s Priority all in a single transaction.

1. Create a New Flow
   
   • In Setup, go to Flows → New Flow → choose Record‑Triggered Flow.
   • Select Object = Case, Trigger = A record is created, and Run this Flow Before the record is saved.
   • Click Done.

1. Get Metadata Mapping
   
   • Drag a Get Records element onto the canvas.
   • Label: Get Priority Mapping
   • Object: Case Origin Priority (your metadata type)
   • Filter: Case Origin Equals $Record.Origin
   • How Many Records to Store: Only the first record
   • Store All Fields.
   • Done.

1. Assign the Priority
   
   • Drag an Assignment element next.
   • Label: Assign Priority
   • In Variable: choose $Record.Priority (this is the record in progress)
   • Set Value to: {!Get_Priority_Mapping.Priority_To_Set__c}
   • Done.

1. Connect & Save
   
   • Connect the Start node to Get Priority Mapping, then to Assign Priority, then to End.
   • Click Save, name it “Case Priority by Origin”, provide a description and then Activate.
     

Just three elements: Start-> Get Records-> Assignment-> End. No extra decision logic, no loops  and no Apex.

Salesforce Best Practices and Declarative Tools

When building scalable, maintainable Flows, always keep these best practices in mind:

1. Before‑Save Flows for Field Updates
   • Using a before save trigger on creation highly reduces DML usage and speeds up execution, because we are modifying the same transaction before it will be committed.
     
2. Limit SOQL to Configuration Data
   • Custom Metadata Types “don’t count” toward the SOQL limits, so querying them in Flows is both safe and efficient.
     
3. Avoid Hard‑Coded Values
   • By reflecting picklist values in metadata, we decouple the Flow logic from specific strings. If we rename a picklist value, just update the metadata no need to edit the Flow whenever something happens.
     
4. Descriptive Naming
   • Use clear, human‑friendly labels for metadata records (e.g., “Web → Low”) so anyone immediately gets each mapping’s use.
     
5. Versioning and Deployments
   • Package both the metadata type definitions and records in change sets or unlocked packages. This ensures production and sandbox environments stay in sync.
     
6. Documentation
   • In the metadata type’s description, briefly note its purpose. In the Flow’s description, mention that it reads from the “Case Origin Priority” metadata. Good documentation saves business hours later.

One of the test result for above implementations:

Once created it should update priority to high as per the requirement:

The Power of Metadata‑Driven Flows

This pattern storing business rules in Custom Metadata and having Flows read them unlocks huge flexibility:

• Business User Friendly: Non technical users can add mappings in the UI without fear of breaking code.
• Rapid Iteration: Add a metadata record and we update immediately.
• Audit Ready: Metadata records carry creation and modification metadata, so we can track who changed a mapping when.
• Consistency: Since metadata types are deployable, guarantee that mappings are identical across sandboxes, staging and production.

Conclusion

Building “Flow with Metadata Type” solutions lets us deliver robust automations that alter effortlessly as the business increases. In few clicks, we have created a fully declarative, metadata driven Case Priority implementation like A Custom Metadata Type to store Origin → Priority mappings, lightweight and before‑save Record‑Triggered Flow that reads that metadata and sets the Case’s Priority. Lastly, zero code, zero additional fields and zero deployments for every mapping change.

By following Salesforce best practices using before‑save Flows, leveraging metadata for configuration and maintaining clear documentation we establish a maintainable, admin‑friendly development. Now, when the stakeholders request to update business logic, we just open the metadata table and make the change in seconds. Happy Building:)