Salesforce Well-Architected: What the new framework changes

The Salesforce Well-Architected Framework has been rebuilt: since 14 September 2026 it has five pillars instead of three, namely Trust, Reliability, Operational Excellence, Resource and Cost Optimization, and Fairness, plus a lens for solutions with AI agents. Before that, the programme had been dormant for almost a year. For CIOs and heads of CRM in manufacturing, one thing is new above all: cost and operations now have pillars of their own. That makes the framework usable as a shared standard for design reviews with several implementation partners. It does not make the trade-offs between the pillars for you.

What happened since the relaunch?

The history is short, but it explains why the framework looks different today:

• After Dreamforce 2024 the website stopped being updated, as Salesforce Ben reported (opens in a new tab). The programme was effectively shut down.
• On 8 August 2025 Chief Architect Emin Gerba and Christophe Coenraets announced its return on the Salesforce blog (opens in a new tab). Remarkably frank: many architects had told them that ending it was a mistake.
• For Dreamforce 2025, from 13 October, the reworked Architecture Center (opens in a new tab) went live, with new decision guides (for example on Data 360, event-driven architecture and asynchronous processing) and new fundamentals on Agentforce and the Agentic Enterprise. Only parts of Trusted and Adaptable in the framework itself were refreshed.
• On 14 September 2026 Salesforce published the new Well-Architected Framework (opens in a new tab). According to Salesforce, hundreds of architects contributed through focus groups, surveys and community events.
• At Dreamforce 2026, according to Salesforce Ben (opens in a new tab), Salesforce added an Architect Agent, an AI assistant in the Architecture Center grounded in this content.

So the real rebuild is the September 2026 version. The 2025 relaunch mainly put the platform around it back on its feet.

What changed in the Well-Architected Framework?

The old framework had three pillars with eight qualities in total: Trusted (secure, compliant, reliable), Easy (intentional, automated, engaging) and Adaptable (resilient, composable). The new framework (opens in a new tab) has five pillars:

1. Trust: security, access, privacy, data governance and integration security.
2. Reliability: availability, recovery and scaling, including disaster recovery and load testing.
3. Operational Excellence: monitoring, DevOps, automation, incident management and continuous improvement.
4. Resource and Cost Optimization: code organisation, packaging, data lifecycle, performance, build versus buy, licences and sandboxes.
5. Fairness: accessibility, transparency, non-discrimination and AI ethics.

Salesforce did not throw the old content away; it re-sorted it. The Legacy Framework Mapping (opens in a new tab) page shows where each part went. Some examples: monitoring used to sit under Reliable and now belongs to Operational Excellence. Disaster recovery used to sit under Resilient and now belongs to Reliability. Business value and ROI used to sit under Automated and now belong to Resource and Cost Optimization. Accessibility and privacy rights sit under Fairness, while legal compliance and data residency stay with Trust. Messaging, eventing and API management moved out of the framework into the Integration Patterns.

What stands out is how concrete the new pages are. A few examples from the text:

• Governor limits: plan with 70 percent of the limits as the ceiling under normal load, so there is headroom for peaks.
• Service levels: set your own solution’s target below the platform SLA, for example 99.5 percent against a 99.9 percent platform SLA, so an error budget remains.
• Disaster recovery: define RTO and RPO per business capability, restore backups regularly, and run a full failover drill once a year for critical systems.
• Multi-org: only when business requirements justify the extra complexity, for example regulatory data isolation.
• DevOps: measure DORA metrics (deployment frequency, lead time, change failure rate, recovery time, rework rate) and check regularly whether production has drifted from what is in version control.
• Accessibility: test against WCAG 2.2 AA.

What does the Agentic Enterprise lens mean?

The second big change is the Agentic Enterprise lens. It is no sixth pillar. Each of the five pillars gets a variant that describes what applies on top when AI agents decide and act on their own: permissions and audit trails for agents, handling failures when several agents are orchestrated, the Agent Development Lifecycle, token consumption and explainable decisions.

The key sentence is in the announcement blog: “Agents don’t get their own rulebook.” An agent has to meet the same requirements for security, stability and cost as any other solution in your org. That matches my stance from Agentforce projects: business value and data quality come before the agent. More on that in Agentforce: business value and data quality first.

What is really new for CIOs and heads of CRM?

From the point of view of a client-side architect, three changes matter.

Cost has its own pillar. In the old framework cost only appeared at the edges. Now licences, sandboxes and build versus buy have a pillar of their own. That was overdue. From my pre-sales work with Salesforce I know that full licences are offered by default, even though many users do not need them. For one client that easily adds up to six figures a year. An architecture review that ignores this is incomplete.

Operations sit next to design as equals. Operational Excellence bundles DevOps, monitoring and incident management. That puts operations into every architecture review instead of leaving them for after go-live. Having DORA metrics in the official framework gives clients an argument with partners who still deploy by hand. Why I insist on this is in Why DevOps matters in Salesforce enterprise projects.

The framework names trade-offs. More encryption and audit logging cost money. Higher availability costs money. More autonomy for agents raises the risk of unfair decisions. Salesforce writes: “The goal is not to maximize every pillar simultaneously.” These trade-offs belong in a decision log, with the name of whoever decided.

Where are the limits of the framework?

For all the agreement: it is still a vendor document.

• It recommends Salesforce tools. Shield Platform Encryption, Event Monitoring and Field Audit Trail are named as solutions. These are paid add-ons. Whether they pay off for your data belongs in the cost pillar, not automatically in the trust pillar.
• The change log has no dates. It lists what was published or enhanced, but not when. If you base architecture decisions on a specific recommendation, record the version with a date in your own decision log.
• The Architect Agent is not tangible yet. Salesforce showed it at Dreamforce but did not state availability or pricing. I would test it before trusting it with architecture questions.
• It does not replace a decision. The framework provides questions and patterns. Whether you need 99.5 percent availability or 99, whether you build or buy, depends on your business model and not on the document.

How do I use the framework in a programme with several partners?

In my largest programme so far, more than 30 developers in 8 streams worked for 5 implementation partners in the same org. It took us about three months to settle the shared standards: naming conventions, one automation per object, test coverage rules, a matrix of which stream owns which object, and rules for what belongs in custom metadata types or custom labels. 80 percent were in place after the first round, the rest was added over the following months.

With the new framework I would sort these standards along the five pillars today. Naming conventions, packaging and object ownership are Resource and Cost Optimization and Operational Excellence. Permissions and integration users are Trust. The advantage: every partner knows the framework, so the discussion does not start from zero, and every deviation can be assigned to a pillar.

In practice that means:

1. Structure design reviews by pillar. Every partner answers the same five blocks of questions for larger changes.
2. Log trade-offs. Where one pillar gives way to another, it goes into the decision log with a reason.
3. Do not treat agents separately. Agentforce work goes through the same review, extended by the agent variant of each pillar.
4. Take the cost pillar seriously. Check licences and sandboxes against actual use once a year.

How I set up standards and reviews in such programmes is part of my work on partner governance and architecture.

Where should you start?

Read the overview in the Architecture Center (opens in a new tab) and the legacy mapping if your teams still work with Trusted, Easy and Adaptable. Then check your existing development standards against the five pillars. Cost and operations are usually what is missing. The new Well-Architected Framework is a useful shared standard as long as you make the decisions yourself. If you want to check your org or your partner standards against it, send me a message.