💃 Design Without Drama 🕺

Good morning, Salesforce Nerds! You know that moment when your VP asks for a “quick” change to how a process behaves?

Suddenly you’re spelunking through a cave system of Flows, Apex, and rogue formula fields? 😮‍💨 

Been there. And it sucks. 👎️ 

Now imagine you live in a world where all you do is tweak a config record. 🌈 

No deploy. No test class triage. No late-night crying.

That’s metadata-driven design: the mature, maintainable way to build Salesforce solutions that flex without fracturing.

Let’s see how … 👇️ 

TABLE OF CONTENTS

💃 Design Without Drama 🕺

• ROYALTY-FREE CONFIG: CMDT REIGNS

• DYNAMIC SOQL: LOGIC THAT LISTENS

• PATTERNS + METADATA = APEX ZEN

• HARD TRUTH & HELPFUL TOOLS

• WRAP-UP: MAKE CONFIG YOUR CO-PILOT

LONG LIVE THE LOGIC OVERLORDS

ROYALTY-FREE CONFIG: CMDT REIGNS

Let’s talk about the tools that make metadata-driven design tick in the world of Salesforce development. 🛠️ 

At the top of the hierarchy? Easy …

Custom Metadata Types (CMDT). The crown jewels 💎 of configurable architecture in Salesforce.

CMDTs behave a bit like custom objects but are built for configuration. ⚙️ 

They’re versioned, deployable, and accessible across Apex, Flows, validation rules, and even formula fields.

Use Cases Include:

↔️ Routing rules

📥️ API endpoints per environment

✅ Feature toggles (Beta features FTW)

🔑 Mapping external to internal values

🤔 Complex decision matrices

CMDTs are especially useful in multi-org or multi-product setups where hardcoded logic becomes an operational liability.

Apex Example:

List<RoutingRule__mdt> rules = [
    SELECT Object_Type__c, Route_To__c
    FROM RoutingRule__mdt
    WHERE Active__c = true
];

for (RoutingRule__mdt rule : rules) {
    applyRoutingLogic(rule.Object_Type__c, rule.Route_To__c);
}

Still holding on to Custom Settings?

You’re not alone. 👍️ IMO CMDTs are superior in most cases, Custom Settings (especially Hierarchy Settings) are still relevant for user or profile specific configuration.

🧠 Just remember: Custom Settings aren’t deployable with their data, and they don’t support all the modern features CMDTs do.

SAY GOODBYE TO IF JUNGLES

DYNAMIC SOQL: LOGIC THAT LISTENS

Metadata on its own is static. 📦️ 

Pair it with Dynamic SOQL and you get a living, breathing engine that changes behavior at runtime based on configuration.

Rather than hardcoding field names or conditions, Dynamic SOQL lets you reference CMDT fields dynamically. ⚡️ 

String fieldName = rule.Field__c;  // e.g., 'Industry'
String value = rule.Expected_Value__c; // e.g., 'Healthcare'

List<Account> matches = Database.query(
    'SELECT Id FROM Account WHERE ' + fieldName + ' = :value'
);

Need to route based on region instead of industry?

Just change the CMDT record. No deploys. No rewrites. 🔥 

This same principle applies in Flow. The Get Records element can use CMDT to power dynamic paths, assignment rules, or even UI behavior.

Perfect for declarative admins looking to level up. ☝️ 

🧠 Important Reminder: Always validate field names to avoid SOQL injection or errors. Dynamic SOQL is powerful, but with great flexibility comes great responsibility.

CHEEKY HEADER

PATTERNS + METADATA = APEX ZEN

The true strength of metadata-driven design reveals itself when combined with Apex Enterprise Patterns like FFLIB. 💪 

Your service classes can consume config like a buffet.

Clean, modular, and testable. 😋 

Need different behavior based on a metadata-driven rule? Inject the strategy, don’t switch on the value.

Example: Metadata-Based Factory Pattern

public class TaxCalculatorFactory {
    public static TaxCalculator getCalculator() {
        String calculatorType = Tax_Config__mdt.getInstance('Standard').Calculator_Type__c;

        if (calculatorType == 'Fancy') {
            return new FancyTaxCalculator();
        }

        return new DefaultTaxCalculator();
    }
}

This design removes hardcoded logic from your classes and lets you control everything from outside the codebase. 🫡 

Your org becomes modular and flexible, like a well-built LEGO set.

Even better, this pattern plays beautifully with Flows. 💥 

CMDTs can control which Flow path executes or which screen component is shown, creating low-code apps with pro-level architecture.

AVOID CONFIG CHAOS (AND THERAPY)

HARD TRUTH & HELPFUL TOOLS

As with any tool, metadata-driven design can become a liability if used recklessly. 🪚 

Here are some hard truths to keep you grounded:

Common Mistakes:

❌ Treating CMDT like data: Don’t store user-generated or transactional data in metadata. It’s config, not a database.

❌ Ungoverned sprawl: Without standards, CMDT records multiply like unreviewed Flows. Use naming conventions and review processes.

❌ Hardcoding CMDT names in Apex: Use getAll() or query by fields, not by name strings that break during rename-a-thons.

❌ Forgetting org limits: CMDTs have limits too. Don’t try to recreate your ERP inside metadata.

Need help managing all this beautifully organized configuration?

Gearset makes deploying CMDT records, diffing config across orgs, and enforcing metadata governance easier than arguing with a MSPL field. 💯 

🌍️ Real-World Win:

In a past project, I built a simple tax engine using a CMDT named Tax_Config__mdt.

Each record mapped a state to a strategy class and rate. 📊 

When state rules changed, no code touched, no deployments needed. 50+ business rules, zero drama.

That’s metadata-driven design doing what it does best: scaling logic without increasing complexity. 🧩 

STOP HARDCODING, START SCALING

WRAP-UP: MAKE CONFIG YOUR CO-PILOT

Metadata-driven design isn’t a hack. It’s a philosophy. 👈️ 

It’s about building systems that evolve gracefully, where logic is cleanly separated from execution and your org becomes more adaptable with every config record you create.

Code less, configure more. ➕ 

And let your architecture do the heavy lifting while you focus on what really matters: delivering smarter, faster, cleaner Salesforce solutions.

That’s the name of game. 🎯 

SOUL FOOD

Today’s Principle

and now....Salesforce Memes