How to Make Impossible Decisions in Salesforce Architecture

Part 113: How to Make Impossible Decisions in Salesforce Architecture

Every Salesforce architect eventually hits the same wall. You’re staring at a whiteboard (or a Miro board, if we’re being honest) with six different approaches to a problem, each one defensible, each one flawed, and a room full of stakeholders waiting for you to pick one. The requirements are contradictory. The timeline is aggressive. And no matter what you choose, someone’s going to tell you it was the wrong call six months from now.

Welcome to the job.

Architecture is not about finding the right answer. It’s about making the best decision you can with incomplete information, under constraints you didn’t choose, and then living with the consequences. The architects who thrive aren’t the ones who always pick correctly — they’re the ones who’ve built a reliable system for making decisions and who can explain why they chose what they chose.

This section is about building that system.

The Problem: Too Many Valid Options

Salesforce is a uniquely brutal platform for decision-making because it gives you so many ways to solve the same problem. Need to automate a business process? You could use Flow, Apex triggers, Process Builder (if you’re maintaining legacy), platform events, or some combination. Need to integrate with an external system? REST, SOAP, platform events, Change Data Capture, Mulesoft, or a managed package from the AppExchange.

None of these options are inherently wrong. Each has trade-offs across dimensions like maintainability, performance, cost, team skill set, governor limits, and long-term platform direction. And this is where most architects get stuck — not because they lack technical knowledge, but because they’re trying to find the objectively correct answer in a space where one doesn’t exist.

The first thing to accept: in most architecture decisions, there are multiple “right” answers. The goal isn’t to find the perfect solution. It’s to pick a good one quickly, document why, and move forward. Indecision is almost always more expensive than a suboptimal choice.

Decision Fatigue and Analysis Paralysis

Decision fatigue is real, and Salesforce architects are particularly susceptible to it. On any given day, you might need to decide on a data model, an integration pattern, a security approach, a UI framework, and a deployment strategy — each with cascading implications.

The danger isn’t making a bad decision. It’s making no decision at all.

I’ve watched projects stall for weeks because an architecture team couldn’t agree on whether to use a custom object or a junction object for a many-to-many relationship. I’ve seen integration projects delayed by months because nobody could commit to synchronous vs. asynchronous processing. In each case, the cost of delay far exceeded the cost of picking the “wrong” option.

Analysis paralysis typically manifests in a few recognizable patterns:

• Endless POCs — Building proof-of-concept after proof-of-concept without ever committing to a direction.
• Death by committee — Routing every decision through a review board that meets biweekly.
• Waiting for perfect information — Refusing to decide until every edge case is mapped and every stakeholder has weighed in.
• Scope expansion — Reframing a simple decision as a much larger architectural concern to justify delaying it.

If you recognize any of these in your team, you don’t have a technical problem. You have a decision-making problem. And that requires frameworks, not more research.

Framework 1: Weighted Decision Matrices

A weighted decision matrix is the most practical tool I’ve found for making complex architecture decisions transparent and defensible. Here’s how it works in practice.

Step 1: Define your criteria. For a Salesforce architecture decision, common criteria include:

• Maintainability (can a mid-level admin/developer support this?)
• Performance (will it scale within governor limits?)
• Cost (licensing, development hours, ongoing support)
• Time to implement
• Alignment with Salesforce platform direction
• Team capability (does your team know how to build and maintain this?)
• Risk (what happens if this fails?)

Step 2: Weight the criteria. Not all criteria matter equally. If you’re building for a startup with three developers, team capability might outweigh performance. If you’re building for a financial services enterprise, risk and compliance might dominate everything else. Assign weights from 1-5 to each criterion.

Step 3: Score each option. Rate every option against each criterion on a 1-5 scale.

Step 4: Multiply and sum.

Here’s a real example. Suppose you’re deciding between Flow, Apex, and a managed package for a complex approval routing engine:

The matrix doesn’t make the decision for you, but it forces you to articulate what matters and why. When someone challenges your choice, you can point to the weights and scores rather than having an abstract argument about which technology is “better.”

Important caveat: The matrix is a tool for structuring thought, not a replacement for judgment. If the numbers say one thing and your gut says another, investigate the gap. Your instinct might be picking up on a criterion you forgot to include.

Framework 2: Reversible vs. Irreversible Decisions (One-Way and Two-Way Doors)

This is the single most useful mental model I’ve adopted for architecture decisions, borrowed from Amazon’s leadership principles.

Two-way door decisions are reversible. If you walk through and don’t like what’s on the other side, you can walk back. These decisions should be made quickly, by individuals or small teams, without extensive analysis.

One-way door decisions are irreversible or extremely costly to reverse. These deserve careful deliberation, broad input, and thorough analysis.

In Salesforce, the distinction looks like this:

Two-way doors (decide fast):

• Choosing a field type for a new custom field (you can change most types later)
• Picking a naming convention for Flow elements
• Deciding whether to use a Screen Flow or an autolaunched Flow for a specific process
• Selecting a Lightning page layout arrangement
• Choosing between a formula field and a Flow-updated field for a calculated value

One-way doors (decide carefully):

• Single org vs. multi-org architecture
• Choosing your integration middleware (Mulesoft vs. custom Apex vs. third-party)
• Data model decisions that affect existing record relationships at scale
• Deciding to build custom vs. buying a managed package for core functionality
• Selecting your source of truth for master data across systems
• Committing to a specific external ID strategy across integrated systems

The tragedy of most architecture teams is that they treat every decision like a one-way door. They bring the same level of rigor to picking a field API name as they do to choosing an org strategy. This is how teams grind to a halt.

The rule: If a decision is reversible, make it in under an hour. Save your deliberation budget for the decisions that actually need it.

When “Good Enough” Beats “Perfect”

Perfectionism is the enemy of delivery. I say this as someone who has personally wasted weeks optimizing an Apex batch class that ran once a month and processed 200 records.

In Salesforce architecture, “good enough” means:

• It meets the stated requirements. Not the imagined future requirements. Not the requirements you think the business should have. The actual, documented requirements.
• It can be maintained by someone other than you. If your solution requires a senior architect to debug, it’s too clever.
• It doesn’t paint you into a corner. Good enough doesn’t mean reckless. It means the solution leaves room to iterate without a full rebuild.
• It ships. The most elegant architecture in the world is worthless if it’s still on the whiteboard when the business needs it in production.

A practical example: you’re building a case routing system. The “perfect” solution might involve a custom Apex engine with configurable rules stored in custom metadata, a slick LWC admin interface, and full unit test coverage. The “good enough” solution might be a well-structured Flow with a few custom metadata records for configuration. If the Flow meets the requirements and can be maintained by your admin team, ship the Flow. You can always refactor later if complexity demands it.

The question to ask is: “What’s the cost of getting this wrong vs. the cost of being late?” For most Salesforce projects, being late is far more expensive than being imperfect.

How to Document and Defend Your Decisions: Architecture Decision Records

An Architecture Decision Record (ADR) is a short document that captures the context, options considered, decision made, and reasoning behind a significant architecture choice. It’s one of the highest-leverage practices an architect can adopt, and almost nobody does it.

Here’s the format I use:

# ADR-001: Integration Pattern for ERP Sync

## Status
Accepted

## Context
We need to synchronize Account and Product data between Salesforce
and our on-premise ERP (SAP). Data changes originate in both systems.
Volume is approximately 5,000 records per day. The business requires
near-real-time sync (< 5 minute delay acceptable).

## Options Considered
1. **Real-time Apex callouts** — Triggered on record save, synchronous
   HTTP callout to ERP. Simple but fragile; governor limits on callout
   time, no retry logic.
2. **Platform Events + Async Processing** — Publish events on record
   change, async subscriber processes the sync. Resilient, scalable,
   but more complex to build and debug.
3. **MuleSoft middleware** — Dedicated integration layer handles all
   orchestration, transformation, error handling. Most robust but
   highest cost and longest implementation timeline.

## Decision
Option 2: Platform Events with async processing.

## Rationale
- Meets the near-real-time requirement within governor limits
- Built-in retry and replay capabilities reduce failure impact
- Team has existing Platform Event experience from a prior project
- Avoids ongoing MuleSoft licensing cost (~$50K/year) that the
  business hasn't budgeted for
- Can be migrated to MuleSoft later if volume exceeds platform
  limits (one-way door analysis: this is a two-way door)

## Consequences
- Need to build custom error handling and monitoring dashboard
- Platform Event daily allocation limit (estimated usage: 40% of
  daily limit) must be monitored
- Team needs to document event schema contracts for the ERP team

The beauty of ADRs is that they protect you and your team in multiple ways:

• Six months from now, when someone asks “why did we build it this way?”, you have a written answer instead of relying on memory.
• During reviews, when a senior architect challenges your approach, you can show you considered alternatives and made a reasoned choice.
• For onboarding, new team members can read the ADR log and understand the system’s evolution without oral history.
• When things go wrong, the ADR shows what you knew at the time of the decision, which is often very different from what you know now.

Store your ADRs in version control alongside your code. They’re living documents — when a decision is revisited and changed, you don’t delete the old ADR. You create a new one that supersedes it, preserving the full decision history.

When to Escalate vs. When to Decide Yourself

This is the question that separates junior architects from senior ones, and it’s more about organizational awareness than technical skill.

Decide yourself when:

• The decision is reversible (two-way door).
• You have the context and expertise to evaluate the trade-offs.
• The impact is contained within your team or domain.
• Delaying the decision would block progress on the current sprint or release.
• You’ve been explicitly empowered to make this category of decision.

Escalate when:

• The decision is irreversible or extremely costly to reverse.
• It affects multiple teams, orgs, or business units.
• It involves significant financial commitment (licensing, third-party contracts).
• It sets a precedent that other teams will follow.
• You lack critical context — for example, you don’t know the business’s five-year platform strategy, and the decision depends on it.
• There’s genuine disagreement among senior technical staff and no clear resolution path.

The most common mistake I see is escalating decisions that should be made locally. Every time you escalate a two-way door decision, you’re training your organization to be slow. You’re also signaling that you don’t trust your own judgment, which erodes the confidence others place in you.

The second most common mistake is failing to escalate one-way door decisions. If you unilaterally commit your organization to a multi-org strategy without executive buy-in, the technical merits of your decision won’t matter when the political fallout arrives.

A useful heuristic: If you’re comfortable writing an ADR for this decision and defending it in a review, decide yourself. If the thought of writing that ADR makes you uncomfortable because you know you’re missing context or stakeholder input, escalate.

Section Notes

Making architecture decisions is a skill, not a talent. Like any skill, it improves with practice and degrades with disuse. The frameworks in this section — weighted matrices, one-way vs. two-way door analysis, ADRs, and escalation heuristics — aren’t magic. They’re tools that impose structure on what is inherently an uncertain, messy process.

The best architects I’ve worked with share a few common traits: they decide quickly on reversible choices, they deliberate carefully on irreversible ones, they document their reasoning, and they’re honest about what they don’t know. None of them get every decision right. All of them have a system for making decisions consistently and learning from the outcomes.

If you take one thing from this section, let it be this: the cost of indecision almost always exceeds the cost of a wrong decision. A suboptimal architecture that ships and gets feedback is infinitely more valuable than a perfect architecture that never leaves the whiteboard. Make the call. Write it down. Move forward.