Salesforce Well-Architected: A Practical Guide to Better Architecture Decisions

What Salesforce Well-Architected is, and is not

An architecture proposal can sound convincing while its criteria remain invisible. One person argues for flexibility, another for speed, another for lower maintenance. Without shared criteria, the team has no reliable way to decide which quality matters most.

Salesforce defines the Salesforce Well-Architected Framework as an opinionated guide to architectural quality on the Salesforce Platform. It supports reviews and trade-off decisions, but it is not a product manual, implementation guide, or source of one correct answer.[1]

CrmWare's interpretation is that the framework should make judgement explicit, not replace it. Knowing it means recognising the guidance. Applying it means showing what changed in a live decision: criteria, accepted trade-off, owner, consequences, and revisit condition. This decision practice is our recommendation, not a Salesforce component.

The five pillars and the mechanisms around them

The current framework uses five quality pillars as decision lenses, not sequential project phases. Trust considers security, access, privacy, and governance. Reliability considers availability, recovery, and scalability. Operational Excellence considers observability, delivery discipline, and the ability to run and improve the solution. Resource and Cost Optimization considers performance, platform consumption, total cost, and value. Fairness considers accessibility, transparency, oversight, and equitable outcomes.[1]

Salesforce's change log identifies the earlier Trusted, Easy, and Adaptable model as legacy and names the current five-pillar taxonomy.[2] Older pages and search results can still surface the former labels, so begin with the current Architecture Center.

The point is not to memorise five definitions. The pillars interact: stronger controls can increase cost or latency; more resilience can add operational complexity; faster delivery can limit time for observability and testing. A well-architected decision chooses a quality profile that fits requirements, risk tolerance, and business context rather than maximising every pillar.[1]

Teams also encounter principles, detailed guidance, patterns and anti-patterns, checklists, decision guides, and a change log. We treat these as working mechanisms, not another official framework layer. Pillars identify the quality at stake; patterns show what good can look like; decision guides evaluate platform options; the change log keeps terminology current.

For a design review, the question is not, “Have we covered the framework?” It is, “Which pillars can materially change this decision, and what happens elsewhere when we optimise for one of them?” That turns a large body of guidance into a focused conversation.

From recommendation to decision: a form architecture example

Consider a hypothetical internal account-onboarding form. It edits one object on a single Lightning page. It needs no public branding or external integration, and administrators will own future changes. The first proposal is a custom Lightning Web Component because custom code offers maximum flexibility.

Before applying the decision practice, flexibility is treated as a requirement, a quality measure, and a reason to select a tool. The proposal moves from preference to build without testing whether that flexibility creates value.

The review changes the sequence:

1. State the context. The business needs a maintainable, accessible form that trained administrators can adjust. It does not currently need a wizard, complex multi-object logic, or precise external branding.
2. Name credible options. Salesforce's form decision guide recommends Dynamic Forms for single-object forms on Lightning pages. Screen Flow, OmniStudio, and custom components serve different combinations of navigation, logic, styling, testing, and deployment needs.[3]
3. Use the relevant pillars. Trust asks how access is enforced. Reliability asks how the transaction fails and recovers. Operational Excellence asks who can deploy, test, observe, and support it. Resource and Cost Optimization asks whether custom build and maintenance buy a needed capability. Fairness asks whether the experience remains accessible.[1] Salesforce advises using Lightning Design System components correctly and testing custom Lightning Web Components with assistive technologies.[4]
4. Make the trade-off explicit. Custom code retains more design freedom, but the stated requirements do not yet justify its additional ownership and test burden.
5. Record the decision. An Architecture Decision Record captures the business drivers, technical constraints, chosen option, rejected alternatives, consequences, technical debt, and revisit triggers. Salesforce includes that record as a pattern for significant architecture decisions.[5]

For this scenario, the record chooses Dynamic Forms. The Salesforce product owner owns the decision, while the administrator team owns day-to-day maintenance. The accepted consequence is less design freedom in exchange for simpler change and support. The team will revisit the choice if the form requires a guided multi-step journey, complex multi-object logic, external branding, or another capability the standard option cannot provide.

The result is not “low code is better than code.” A custom component remains a valid future option. The difference is that the choice now has a defined scope, an accountable owner, visible consequences, and a condition for revisiting it.

What the framework cannot decide for you

Salesforce Well-Architected does not tell a team which business outcome to pursue. It does not resolve conflicting requirements, set the organisation's risk tolerance, assign governance authority, or prove that an implementation works. Salesforce's architecture patterns place functional and non-functional requirements analysis before significant build investment.[5] Its Reliability guidance is equally direct: define business requirements before selecting technical solutions.[6]

The framework supplies shared quality questions, but it cannot replace accountable people. Engineering tests assumptions. Governance decides who may accept risk. Product ownership connects architecture to a business outcome.

CrmWare recommends starting with one pending choice, not programme-wide compliance. Choose a material but reversible decision. Time-box the first review to 45 minutes and bring the intended outcome, constraints, credible options, and owner. Use the pillars that can change the choice, then check consequences across the others.

That record is the difference between reading Salesforce Well-Architected and using it as a team capability.

References

[1] Salesforce Architects. Well-Architected Framework. 2026. https://architect.salesforce.com/docs/architect/well-architected/guide/framework.html

[2] Salesforce Architects. Change Log. 2026. https://architect.salesforce.com/docs/architect/well-architected/guide/change-log.html

[3] Salesforce Architects. Building Forms. 2026. https://architect.salesforce.com/docs/architect/decision-guides/guide/build-forms

[4] Salesforce Architects. Fairness. 2026. https://architect.salesforce.com/docs/architect/well-architected/guide/fairness.html

[5] Salesforce Architects. Architecture Patterns. 2026. https://architect.salesforce.com/docs/architect/well-architected/guide/resource-and-cost-optimization-architecture-patterns.html

[6] Salesforce Architects. Reliability. 2026. https://architect.salesforce.com/docs/architect/well-architected/guide/reliability.html