Salesforce Well-Architected: trust first, ease second, adaptability third
Salesforce's Well-Architected framework is the only major cloud-platform framework that ranks its own pillars. Here's why the order matters — and what 'Trusted is non-negotiable' looks like in practice.
Salesforce shipped its own Well-Architected framework after AWS made the form factor canonical. What makes the Salesforce version interesting isn’t the structure — there are still pillars under pillars under patterns — it’s that the company did something AWS deliberately avoided: it ordered its three top-level capabilities.
The order is Trusted → Easy → Adaptable. And the order is the design.
The three capabilities, plainly
Trusted (priority 1). A trusted solution protects your business and your stakeholders. It is the only capability Salesforce describes as never tradeable. Concretely, it groups three behaviors:
- Secure: organizational security, session security, data security.
- Compliant: legal adherence, ethical standards, accessibility.
- Reliable: availability, performance, scalability.
If a design move would compromise any of these, the move is wrong. Not “wrong unless the business says otherwise” — wrong.
Easy (priority 2). An easy solution delivers business value fast. This is the capability that earns its keep every day, not just on incident response. Three behaviors:
- Intentional: strategy, maintainability, readability.
- Automated: efficiency, data integrity.
- Engaging: streamlined UX, helpful design.
Adaptable (priority 3). An adaptable solution evolves with your business. The last capability isn’t last because it doesn’t matter — it’s last because the first two have to be solid before you can responsibly invest in flexibility you don’t need yet. Two behaviors:
- Resilient: app lifecycle management, incident response, continuity planning.
- Composable: separation of concerns, interoperability, packageability.
The taxonomy, four levels deep
Salesforce’s framework drills further than the pillar layer:
- Capability — top-level quality (e.g., Trusted).
- Behavior — how a solution exhibits that capability (e.g., Secure).
- Dimension — the specific area you’re prioritizing (e.g., Data Security).
- Consideration — a concrete pattern or anti-pattern (e.g., “Avoid SOQL in loops”).
Most engagement conversations live at the Consideration level. That’s where the Pattern Explorer at architect.salesforce.com earns its keep — it’s a searchable catalog of patterns and anti-patterns keyed to the framework. We treat it as the first stop when reviewing legacy orgs.
Anti-patterns are the better entry point
The honest way to use the framework is to start at the anti-patterns, not the patterns. The anti-pattern list is shorter, more visceral, and — frankly — more often where the work is. The five we find ourselves naming most often on intake calls:
- Weak access controls. Treating sharing as an afterthought, layered defenses skipped because they’re “complicated.” Maps directly to Trusted → Secure.
- Non-selective SOQL. Queries that scan, formulas in WHERE clauses, joins across millions of rows. Trusted → Reliable, also Easy → Automated.
- Tightly coupled design. Triggers calling triggers, flows reading from triggers, a monolith of references that no one wants to refactor. Adaptable → Composable.
- Skipping risk assessment. Backup ≠ continuity planning. Adaptable → Resilient.
- No production-scale testing. Coverage isn’t the same as confidence. Trusted → Reliable.
When you start a Well-Architected review with anti-patterns, you usually find which capability is actually under-invested. The “what do we improve next” answer falls out without anyone having to argue about it.
How it compares to AWS
| Aspect | Salesforce | AWS |
|---|---|---|
| Top-level structure | 3 Capabilities | 5 Pillars |
| Priority ordering | Yes — Trusted is always #1 | None explicit |
| Platform scope | Customer 360 Platform | Cloud infrastructure |
| Review surface | Pattern / Anti-Pattern Explorer | AWS WA Tool |
| Non-negotiable | Trusted | Security + Operational Excellence |
The Salesforce decision to rank its capabilities is the substantive philosophical difference. AWS treats its pillars as orthogonal axes; you accept trade-offs across them depending on the workload. Salesforce treats Trusted as a constraint, not a knob. We think that’s right for a multi-tenant platform handling customer data by default — trust is the table-stakes the platform is built around, and pretending otherwise produces designs that get bailed out by Salesforce’s own platform-level controls rather than by your architecture.
What to do this week
If you’ve never run a Well-Architected review on your org, the first version takes about half a day:
- Pick the three or four anti-patterns you most suspect.
- Walk one prod release path against each.
- Score each against the relevant Behavior and write one paragraph per Consideration that fails.
You’ll have a list of two to five real problems. Pick the cheapest, fix it next sprint, and put a calendar reminder for the next review in ninety days. The framework rewards being used regularly — not exhaustively, once.
For more on the AWS side of this same conversation, see The AWS Well-Architected Framework, distilled. For the PaaS perspective, see The Twelve-Factor App: still the cleanest playbook for Heroku.