A routing rule buried in a Flow decision is easy to forget until the sales team changes territories. Custom metadata gives you a place to store that rule as configuration, so approved changes don’t require rewriting every automation that uses it.
For RevOps teams, it works well for country rollout switches, routing mappings, and other small rule sets. It has clear limits: credentials belong elsewhere, and metadata doesn’t assign territories or handle exceptions on its own. Start with one workflow whose behavior you need to change safely.
Key Takeaways
- Use custom metadata types for deployable configuration, such as country-level feature flags and stable routing mappings.
- Record triggered flows can read metadata with Get Records, while Apex uses type-specific
getInstance()andgetAll()methods. - Keep API keys and tokens out of metadata. Use Salesforce Named Credentials for external-service authentication.
- Define what happens when a rule is missing, then test that outcome before rollout.
- Choose a custom object instead when operations staff need frequent edits, reporting, or a business-record lifecycle.
Where Salesforce custom metadata fits
Custom metadata types define fields for configuration records. A custom metadata object represents deployable configuration, not an ordinary business-record custom object. For example, a Country_Rollout__mdt type might hold one record per country, with a checkbox controlling whether an onboarding task gets created.
Salesforce treats custom metadata records as deployable metadata, so teams can move approved rules alongside the automation that reads them.
That distinction matters when several people maintain a CRM. A RevOps owner can review a named country rule more easily than a hardcoded value buried in Apex triggers. Still, the automation must define how to interpret the record. Metadata stores the instruction; Flow or Apex carries it out.
A good candidate is a small, relatively stable set of rules that should move between environments. These rules are configuration data, while values that change with every sales transaction are probably business data instead.
Build a configurable onboarding rule in Setup
Suppose an Opportunity reaching Closed Won should create an onboarding task, but only after that country’s process is ready. This example uses a custom Opportunity picklist, Country_Code__c, with controlled values such as US and CA. Use the field your organization actually governs; free-text country names invite mismatches.
- In a sandbox, open Setup, search for Custom Metadata Types, and select New Custom Metadata Type. Name the type Country Rollout. Salesforce assigns an API name such as
Country_Rollout__mdt. Save it. - On the type’s detail page, add custom fields, including a checkbox called Create Onboarding Task with an API name such as
Create_Onboarding_Task__c. When checked, the field means the task-creation path is available for that country. - Select Manage Records and create custom metadata records with Developer Names
USandCA. Keep these names aligned withCountry_Code__c. Check the box for a country that’s ready; leave it unchecked for one that isn’t. - Document the rule’s owner, the reason for each setting, and the expected result when no matching record exists. For this workflow, a missing rule should suppress the onboarding task and create an operations-review exception.
Developer Name is a useful lookup key because the automation can match it to a controlled country code. Don’t treat a blank or missing record as permission to proceed. An absent MX rule, for example, could otherwise start an unapproved handoff.
This pattern controls one action. It shouldn’t silence unrelated validation rules, ownership updates, or customer notifications.
Read the rule in Flow or Apex
Metadata can support both no-code and coded automation, but the retrieval steps differ. Choose the path that owns the decision, rather than building two copies of the same rule.
In a record-triggered Flow
Create an after-save record-triggered Flow on Opportunity for the handoff. Check that the stage changed to your organization’s closed-won stage, not merely that the record currently has that stage. That condition helps prevent an unrelated edit from creating another task.
In record triggered flows, add Get Records for Country_Rollout__mdt. Filter DeveloperName to match the Opportunity’s Country_Code__c, and retrieve the first matching record. A Decision element then checks whether a record was found and whether Create_Onboarding_Task__c is true. Create the task only on that branch; send a missing rule to the exception path.
Salesforce’s Flow and custom metadata lesson covers reading metadata records in Flow Builder. Test this design in the actual Flow execution context. Don’t assume every automation tool or external integration has Flow’s Get Records access.
In an Apex handler
When Apex code owns the handoff, Country_Rollout__mdt.getInstance(countryCode) retrieves one record by Developer Name. Check for null before reading Create_Onboarding_Task__c.
For bulk custom metadata retrieval, Apex triggers processing many Opportunities can call Country_Rollout__mdt.getAll() once, outside the record loop. Look up each country in the returned map to avoid repeating retrieval work. Salesforce documents these options in its custom metadata type methods reference.
These static methods don’t use the SOQL engine. An optional, org-built custom metadata utility can centralize shared Apex logic, but it isn’t a built-in Salesforce feature. SOQL remains available for query-style filtering, but neither approach removes the need to bulkify record processing. Task creation, other queries, and downstream automation still need limit-aware design.
Model state-to-territory rules without confusing access
Country flags are simple lookups. Territory routing needs more care because a geographic mapping isn’t the same as native territory management or Salesforce territory membership.
Keep the geographic key unambiguous
For a small US routing model, a State_Routing_Rule__mdt type could hold a state code, a sales-region code, and a fallback queue identifier. Give each state one governed record. The automation reads the Account’s normalized state code, finds the rule, and chooses the next routing action.
If multiple countries share subdivisions with the same abbreviation, key the rule by country plus subdivision, rather than state alone. As the model grows, a parent child relationship can connect state mappings to separate region configuration records. That reduces repeated region settings, but the relationship doesn’t assign records automatically.
Decide whether native territories are required
A metadata mapping can tell custom automation which owner or queue to choose. It doesn’t, by itself, create territory associations, grant record access, or resolve overlapping sales coverage.
If your team needs accounts assigned to Salesforce territories, territory-based access, or a maintained territory hierarchy, evaluate Enterprise Territory Management and its assignment rules. Use metadata for a narrower routing policy when the native territory model would solve a different problem. In either design, send unknown states to a fallback queue rather than guessing an owner.
Use feature flags for phased country rollouts
The onboarding checkbox lets RevOps activate one defined behavior for US while keeping CA inactive. A similar setting could control whether a country-specific notification fires during a phased rollout.
Scope flags to one decision
Name a setting after the action it controls, such as Create Onboarding Task. A broad Bypass All Automation setting can suppress validation, routing, and audit behavior that other teams depend on. Narrow settings make reviews and rollback decisions clearer.
If MuleSoft integrations send records into Salesforce, decide who owns the switch. Salesforce-owned automation must read it in Flow or Apex; an integration can’t automatically call Apex’s getInstance() or inherit Flow access. Changing metadata doesn’t automatically update upstream processes.
Set a safe default
A missing or inactive setting needs an explicit path. For onboarding, create no standard task and send an exception to RevOps for review. Also decide what happens if a country code changes after an Opportunity closes, or if a deal reopens and closes again.
A setting prevents a branch from running, but it doesn’t make the branch idempotent. Check for an existing handoff or use a governed handoff marker before creating another task.
Keep integration secrets out of metadata
An endpoint URL or non-sensitive integration setting may look like configuration. An API key embedded in that URL is a secret. Moving an API key into a custom metadata record doesn’t secure it.
Salesforce’s guidance on storing sensitive data identifies a Named Credential as a secure option for authentication data used in external callouts. Store the API key there. Pair a Named Credential with metadata only when you need separate, non-secret behavior settings, such as whether an integration path is enabled.
For integration security, also review who can inspect metadata through Setup, deployment tools, packages, and API access. Protected metadata has particular managed-package behavior; it isn’t a general-purpose vault for an ordinary org. Salesforce’s CustomMetadata class documentation warns against storing secrets or private data in custom metadata types.
Choose the right home for each rule
Salesforce custom metadata is one configuration option, not the default for every RevOps setting.
| Option | Good fit | Watch for |
|---|---|---|
| Custom metadata type | Deployable custom metadata object records for stable rules, including state-to-territory mappings when native territory management isn’t needed | Edits require configuration governance; don’t store secrets |
| Custom setting | Org-level or user-level settings in a design that calls for them | Different behavior and deployment model |
| Custom object | Frequently edited, reportable business records | Data access, storage, and DML considerations |
| Named Credential | External endpoint and authentication credentials, such as an API key | It doesn’t replace routing or rollout logic |
Salesforce documents custom settings in Apex, including hierarchy settings. Compare that option when behavior must vary by user or profile. Choose a custom object if sales operations needs to edit exceptions as working records, report on them, and track their lifecycle.
The split can be practical: keep the approved routing rule in metadata, but store a failed-routing case in a reportable object or queue. The rule and its operational exception have different jobs.
Deploy, test, and maintain the configuration
A working sandbox Flow isn’t a complete rollout. The type, its fields, its records, and the automation must all reach the target environment in a compatible state.
Deploy the rules with their consumers
Use your supported metadata deployment or packaging process to move the type and records with the Flow or Apex that reads them. Confirm that the target org has the expected Developer Names and field values before activation. A Flow deployed without its US record will take the missing-rule path even though its logic is correct.
Keep the API key in its Named Credential, not in deployed metadata.
Restrict who can change configuration in Setup and review metadata access for the users and execution contexts involved. Test with a representative non-admin user and the integration user, not only a system administrator. Record who approves flag changes so a country launch doesn’t depend on an undocumented checkbox edit.
Test business outcomes, not just retrieval
In a sandbox, test an enabled country, a disabled country, and an unknown code. Then test bulk Opportunity updates, a repeated save, a reopened deal, and a task-creation failure. Verify that each exception reaches its intended owner or queue.
Tests in Apex code can read custom metadata records without SeeAllData=true. Still, tests that rely only on records present in one org are fragile. Include representative metadata with the deployment and test missing-record behavior. Test authentication with the API key without exposing the secret in logs or automation output. Finally, monitor exception volume after launch. A spike can reveal a new country value or an incomplete deployment before customers miss a handoff.
Frequently Asked Questions
Can a record-triggered Flow use custom metadata?
Yes. A Flow can use Get Records to retrieve a custom metadata type record, then evaluate its fields in a Decision element. Check the behavior in that Flow’s execution context. Apex’s static retrieval methods are separate Apex features.
Should every US state have its own metadata record?
That can work when each state has a stable routing rule. Use controlled state codes and define a fallback for missing mappings. If assignment depends on changing account attributes or overlapping territories, assess whether native territory features or a different data model fit better.
Can RevOps update a flag directly in production?
An authorized administrator may be able to edit a metadata record, but the change should still follow an approval and test process. A live flag change can affect the next transaction immediately. Document the owner, expected behavior, and rollback value before using it during a rollout.
Conclusion
Hardcoded routing decisions become costly when business changes faster than automation releases. A sound custom metadata strategy keeps each rule narrow, clearly named, and deployed with the process that reads it.
Start with one controlled decision, such as a country-level onboarding flag. Define what happens when a rule is missing, keep credentials in Named Credentials, and test the handoff as a sales user would experience it.
