💃 Architected, Not Accidental 🕺

Good morning, Salesforce Nerds! Most Salesforce orgs don’t fail loudly. They fail politely. 😇 

Page loads slow down a little. Flows get “temporarily” cloned. Error emails quietly stack up in someone’s inbox.

Six months later, everyone agrees the org feels fragile, expensive, and oddly hostile to change. 😡 

That’s the problem the Salesforce Well-Architected Framework is meant to solve.

Not by handing you a checklist. Not by telling you which feature to click. 🙅 

But by giving teams a shared way to think about architecture before production teaches the lesson the hard way.

Well-Architected isn’t about perfection. ✨ 

It’s about making conscious tradeoffs, designing for failure, and keeping today’s shortcut from becoming tomorrow’s outage.

TABLE OF CONTENTS

💃 Architected, Not Accidental 🕺

• Principles, Not Playbooks

• The Five Pillars

• Pillars in Practice

• Tradeoffs & Anti-Patterns

• Design Before Delivery

GUIDANCE OVER GOSPEL

PRINCIPLES, NOT PLAYBOOKS

The Salesforce Well-Architected Framework is a set of guiding principles, not prescriptive best practices. ⛔️ 

It doesn’t say “always use Flow” or “never write triggers.”

It asks better questions:

🤔 What happens when this fails?

🤔 Who owns this in production?

🤔 How does this behave at scale?

🤔 What does it cost to run and to change?

That distinction matters. Prescriptive rules age quickly. Principles don’t.

Teams get into trouble when they treat Well-Architected like a compliance exercise.

A slide deck. A box to check after delivery. Used that way, it becomes architectural theater. 🎭️ 

Used correctly, it becomes a design-time filter that shapes decisions long before code is written. 🔥 

Think of it less like a rulebook and more like a seasoned architect sitting in the room asking uncomfortable but useful questions.

FIVE LENSES, ONE SYSTEM

THE FIVE PILLARS

Salesforce Well-Architected is organized around five pillars.

Each one represents a different lens on system health. 🔍️ 

None stand alone.

👉️ Operational Excellence asks whether you can run what you build. Monitoring, logging, deployments, incident response, and ownership live here.

👉️ Security focuses on protecting data and access. Least privilege, data exposure, auth boundaries, and auditability.

👉️ Reliability is about surviving failure. Retries, idempotency, concurrency control, and graceful degradation.

👉️ Performance looks at speed and scalability. Bulk safety, async boundaries, query selectivity, and user-perceived latency.

👉️ Cost examines efficiency. Not just licenses, but compute, automation churn, and the human cost of complexity.

Strong architectures balance all five. ⚖️ 

Weak ones optimize one pillar while quietly sabotaging the rest.

WHERE THEORY MEETS APEX

PILLARS IN PRACTICE

This is where Well-Architected stops being abstract.

Take a common enterprise scenario: assigning work in real time under load. 🚛 

A naive implementation might query, assign, and update in one synchronous transaction.

It works. Until it doesn’t. 😅 

A Well-Architected approach designs for contention and failure up front.

Some quick psuedo-code to illustrate:

public static void assignWork(Id workId) {
    try {
        Work__c w = [
            SELECT Id, Status__c
            FROM Work__c
            WHERE Id = :workId
            FOR UPDATE
        ];

        if (w.Status__c != 'Available') return;

        w.Status__c = 'Assigned';
        update w;

    } catch (QueryException | DmlException ex) {
        System.enqueueJob(new RetryAssignment(workId));
    }
}

This single snippet touches multiple pillars: 😋 

• Reliability: Row locking prevents double assignment.

• Performance: Minimal query scope, no unnecessary joins.

• Operational Excellence: Explicit retry path instead of user re-clicking.

• Cost: Async retries reduce failed transactions and support churn.

Same feature. Very different outcome.

Flow-first designs follow the same logic. Orchestration in Flow. Decision-heavy, failure-aware logic in Apex.

Fault paths are not optional. They are architecture. 💯 

YOU CAN’T WIN EVERYTHING

TRADEOFFS & ANTI-PATTERNS

Every pillar pulls against the others. That’s normal.

• Adding retries improves reliability but increases cost. 📈 

• Heavy validation improves security but hurts performance. 📉 

• Async processing improves scale but complicates operations. 🧩 

Well-Architected doesn’t eliminate tradeoffs. It makes them explicit.

It also helps teams avoid familiar Salesforce anti-patterns:

• Flow spaghetti that encodes business rules across ten versions.

• Triggers acting as integration layers.

• “Retry by clicking Previous and Next.” 🤮 

• Synchronous callouts in user flows.

• Security enforced in UI instead of data access.

These aren’t skill problems. They’re design problems. 🥹 

ARCHITECTURE IS UPSTREAM

DESIGN BEFORE DELIVERY

The biggest Well-Architected mistake is applying it after go-live. 💥 

At that point, you’re refactoring under pressure.

Used correctly, the framework becomes a shared language:

• Architects explain tradeoffs to stakeholders.

• Developers align on patterns. 🥳 

• Admins understand why guardrails exist.

• Leaders measure health beyond feature count.

Architectural health shows up in signals like:

• Error rates and retries

• Queue depth and async backlogs

• Deployment frequency and rollback confidence 🌟 

• Test stability and execution time

When those improve, velocity follows. 💨 

Well-Architected isn’t about building castles. It’s about building systems that survive real users, real load, and real change. ✔️ 

If your org feels fragile, it’s not because Salesforce is. It’s because architecture was accidental.

Design it on purpose. 🫡 

SOUL FOOD

Today’s Principle

and now....Salesforce Memes