Stories tagged custom-metadata-types

Thresholds, defaults and feature switches tend to get typed straight into whichever formula, Flow or Apex class needs them. The cost shows up later, when the business changes a number and someone has to find every place it was used. Andrew Fawcett argues that Custom Metadata Types are the platform’s answer: a single, deployable home for those values that travels through source control with the rest of the application, unlike records in a Custom Object or Custom Settings.

The post works through a deal-policy example. A Deal_Policy__mdt type holds a large-deal amount, a maximum discount, a default discount and an approval threshold, with one record per region and a Default record for org-wide values. A Formula Field reads the Default record directly using the $CustomMetadata reference, which names the type, the record and the field. The same shape works in Validation Rules and field defaults, though long text area fields cannot be referenced this way.

From there it covers each consumer in turn: formulas, Validation Rules, Flow, Apex, Lightning Record Pages and Agentforce, noting which support the reference natively and which need a workaround. A sample project deploys to a Scratch Org so readers can follow the same Setup paths. The harder question the post keeps returning to is impact: once the value lives in one place, how do you find out what reads it and what changes when you edit it.