How do you use Custom Metadata Types as an architecture pattern?

Custom Metadata Types (CMDTs) are a powerful architectural primitive — config + metadata + cache, all in one.

Patterns:

1. Feature flags.

• Feature_Flag__mdt with Enabled__c boolean.
• Apex / Flow checks Feature_Flag__mdt.getInstance('NEW_PRICING').

2. Integration endpoints.

• Integration_Config__mdt with endpoint URL, timeout, etc.
• Apex callouts read from CMDT, not hardcoded.

3. Business rules.

• Discount_Rule__mdt with criteria + threshold.
• Apex / Flow walks CMDT records to find matching rule.

4. Mappings.

• External_System_Map__mdt for code-to-record-type translations.
• Integrations look up via CMDT.

5. Trigger handler routing.

• Trigger_Handler_Map__mdt mapping sObject -> handler class.
• Trigger framework reads CMDT to dispatch.

6. Validation rule complexity.

• Validation rules can reference CMDT via $CustomMetadata. Threshold values defined in CMDT, not hardcoded.

7. Per-environment config.

• CMDT records can vary across orgs; deploy specific values per env.

Why CMDT works for these:

• Deployable — values move with code.
• Cached — no SOQL governor cost.
• Type-safe — fields have types, validated at deploy.
• Queryable from formula and validation rules.
• Packageable — managed packages can ship CMDT.

Anti-pattern: Custom Settings for what should be CMDT. Custom Settings data doesn't deploy; CMDT does.

Architect insight: CMDT-driven architecture lets admins tune behaviour without redeploys. Reduces dev burden; increases agility.