The Salesforce Well-Architected Framework gives architects a shared, principled foundation for making the decisions that help a solution succeed over time. It’s organized around five pillars—Trust, Reliability, Operational Excellence, Resource and Cost Optimization, and Fairness—each of which captures a dimension of quality that matters across every stage of a solution's life, from initial design through long-term operation and growth.

The framework addresses the realities architects face today: humans, agents, and platforms working together inside governed business systems. A solution that is secure but brittle under load, or efficient but opaque in its decisions, is not well-architected. These five pillars work together to ensure that quality is treated as a whole rather than a checklist of independent concerns.

Architects use the framework as a consistent lens during design reviews, trade-off conversations, and ongoing governance. It does not prescribe a single right answer. It gives you the right questions to ask, the right patterns to consider, and a common vocabulary to use across teams.

Note: Review the Change Log to see recent updates to the Architecture Center documentation.

The Salesforce Well-Architected Framework is an opinionated guide to architectural quality for solutions built on the Salesforce Platform. It codifies the principles, patterns, and trade-offs that distinguish solutions that scale and adapt from those that accumulate technical debt or fail under pressure.

The framework is organized around five pillars. Each pillar defines a dimension of quality, articulates core design principles, identifies common patterns, and provides explicit guidance for both traditional platform capabilities and agentic AI workloads. Together, the pillars comprehensively cover what it means to build something well on Salesforce.

This framework is not a product manual or an implementation guide. It is an architectural decision framework—a way of thinking about quality that applies regardless of which clouds, features, or tools a solution uses.

Industry frameworks from hyperscale cloud providers give valuable general guidance, but they are built primarily for cloud-infrastructure and operational concerns, such as virtual machines, networking, storage, and compute. Salesforce architects face different constraints and capabilities: multitenant platform with governor limits, decades of business logic in Customer 360, sophisticated integration solutions, declarative automation, metadata-driven configuration, and managed sharing models. These shape every architectural decision in ways that generic cloud guidance cannot address.

The shift to autonomous agents introduces additional considerations. Agents that reason and act introduce non-determinism, probabilistic reasoning, and Human-in-the-Loop oversight patterns that earlier frameworks did not originally address, though general-purpose frameworks have begun extending into this space through dedicated AI lenses. The Salesforce Well-Architected Framework addresses both traditional platform architecture and agentic systems through a unified lens.

This framework serves anyone responsible for architectural quality on the Salesforce platform:

• Salesforce Architects designing new solutions or extending existing ones
• Salesforce Admins configuring and securing the orgs where these solutions run
• Development Leads establishing standards and patterns for their teams
• Consultants and Partners advising customers on platform best practices
• AI and Agentic Specialists building and governing autonomous agent systems

No prior expertise in agentic AI is required. The framework is accessible to all architects while providing depth for those working at the frontier of autonomous systems.

There is no single correct reading order. Choose based on your role and immediate need:

• If you are new to the framework: Read this overview document end to end, and then explore the pillar most relevant to your current project.
• If you are designing a new solution: Start with Trust and Reliability (non-negotiable foundations), and then address Operational Excellence (how you will operate it), Resource and Cost Optimization (how you will sustain it), and Fairness (how you will make sure it serves all users equitably).
• If you are building agentic solutions: Read the Agentic Enterprise Overview first for comprehensive agent architecture guidance. Then read the core pillar documents (linked above) for foundational patterns—Shared Responsibility Model, governor limits, monitoring tools, TCO modeling, accessibility standards—that agentic solutions build upon. Finally, reference the Agentic Enterprise pillar variants (linked from each pillar) for agentic-specific overlays on each quality dimension.
• If you are conducting a design review: Use the pillar documents as a structured review checklist. A well-architected solution has clear answers to the key questions in each relevant pillar.

The most important architectural decisions involve trade-offs between pillars. The framework helps you make these explicit:

• Trust vs. Resource and Cost Optimization: Encryption and audit logging consume resources. The framework helps you identify where the trust requirement is non-negotiable versus where you have flexibility.
• Reliability vs. Resource and Cost Optimization: Higher availability costs more. SLO definitions help you match investment to actual business requirements rather than defaulting to maximum redundancy.
• Operational Excellence vs. Speed: Comprehensive observability and testing take time to implement. The framework helps you identify the minimum viable observability for your risk profile.
• Fairness vs. Autonomy: Greater agent autonomy enables efficiency but creates fairness risk. Human-in-the-Loop patterns help you find the right balance for each decision type.

There is no universal answer to these trade-offs. The framework helps you ask the right questions and make the trade-offs consciously rather than discovering them in production.

The Well-Architected Framework itself is designed with these principles in mind:

• Platform-specific but technology-agnostic: Guidance addresses Salesforce-specific constraints (governor limits, multitenant architecture, metadata-driven configuration) without prescribing specific products or features. Architects choose the right capabilities for their context.
• Opinionated without being prescriptive: The framework takes clear positions on what constitutes quality but does not dictate a single implementation path. It provides principles, patterns, and questions—not requirements.
• Forward-looking while respecting the present: The framework addresses emerging patterns (agentic AI, autonomous systems) while remaining relevant to traditional platform solutions. Both use cases benefit from the same foundational principles.
• Living, not static: The framework evolves as the platform, industry practices, and customer needs change. The Change Log tracks updates so architects can stay current with new guidance.
• Actionable at every stage: Whether you are designing a new solution, conducting a review, or improving an existing implementation, the framework provides relevant guidance. It is not just a certification checklist—it is a working tool.

These principles ensure the framework remains useful across diverse architectural contexts while maintaining clear, consistent guidance on what architectural quality means for Salesforce solutions.

Each pillar addresses a fundamental dimension of architectural quality. Together, the pillars provide comprehensive coverage—no single pillar is sufficient on its own, and trade-offs between pillars are where the most important architectural decisions live.

The five pillars that follow provide foundational architectural guidance for all Salesforce solutions—traditional platform applications, integrations, and agentic systems alike. The Agentic Enterprise Overview and its companion pillar variants provide the agentic-specific overlay: how agents build on these capabilities, what changes when systems act autonomously, and the architectural patterns required for governed AI.

Use both together:

• Start with the pillar guidance for core architectural patterns (for example, the Shared Responsibility Model, governor limits, monitoring tools, TCO modeling, accessibility standards).
• Then, reference the corresponding Agentic Enterprise pillar for agentic-specific considerations (for example, agent permissions and audit chains, orchestration failure handling, Agent Development Lifecycle, token optimization, Agentic Work Units, explainability and contestability).

The pillars are not "traditional" vs. "agentic"—they are foundational architecture that agentic solutions build upon. Agentic systems must satisfy the same trust, reliability, operational excellence, resource and cost optimization, and fairness requirements as any other enterprise solution, with additional considerations for autonomous operation.

This table provides a quick reference. Detailed guidance for each pillar follows.

Protect your solution, its data, and its users through modern security, least-privilege access, privacy controls, and clear governance. Trust on Salesforce operates through the Shared Responsibility Model: Salesforce secures the infrastructure and platform, then you architect secure solutions on that foundation. Your responsibility spans:

• Identity and access management (roles, profiles, permission sets, MFA, SSO, OAuth)
• Data governance (Shield Platform Encryption, object/field/record-level security)
• Integration security (API authentication, named credentials)
• Secure development practices (OWASP Top 10 adapted for Salesforce, static analysis, CI/CD security gates)

For Agentic Solutions: When agents act autonomously, trust requirements extend to governing what agents are permitted to do, auditing what they have done, and securing agent-to-platform boundaries (Agent Fabric, Einstein Trust Layer).

To learn more, see the Trust pillar and Agentic Enterprise Trust.

Design for continuous availability, fast recovery from disruption, and the capacity to scale under unexpected demand. Reliability requires understanding platform guarantees (multi-region infrastructure, platform SLAs) while designing solutions that remain reliable within those constraints. The pillar covers:

• Governor limits with 70% operational ceiling guidance
• Async processing patterns (Batch Apex, Queueable Apex, Platform Events)
• Circuit breakers for external integrations
• Capacity planning
• Load testing
• Multi-org patterns
• Disaster recovery
• Health modeling

For Agentic Solutions: Agent-driven systems introduce probabilistic behavior requiring new patterns for orchestration failures, circuit breakers for cascading agent errors, and deterministic Agent Graphs where business outcomes require predictability.

To learn more, see the Reliability pillar and Agentic Enterprise Reliability.

Build comprehensive observability into your solution and manage it through well-defined procedures and automation. Operational Excellence spans:

• Observability (Event Monitoring, Proactive Monitoring, Scale Center)
• DevOps practices (source-driven development, CI/CD pipelines, testing strategy)
• Automation (declarative-first with Flow Builder, programmatic patterns with Apex)
• Incident management (severity levels, on-call rotation, blameless postmortems)
• Continuous improvement (DORA metrics, operational reviews)

For Agentic Solutions: Observability becomes harder when system behavior is probabilistic. The Agent Development Lifecycle (ADLC) provides structure through five phases: ideation and design, development, testing and validation (including agent Testing Center evaluations for accuracy, coherence, and instruction adherence), deployment and release, and monitoring and tuning (including Agentforce Session Tracing for end-to-end interaction visibility).

To learn more, see the Operational Excellence pillar and Agentic Enterprise Operational Excellence.

Return maximum business value for every dollar and every unit of platform resource, through efficient use of what you have and deliberate investment in what you buy. On the resource side, this means understanding governor limits (SOQL queries, DML statements, heap size, CPU time) and designing within them through SOQL optimization, async processing, and data skew prevention. On the cost side, it means comprehensive TCO modeling across both direct costs (implementation, operational, maintenance) and indirect costs (technical debt, governance overhead) that often exceed direct license costs. The pillar covers:

• Code organization patterns (trigger handlers, service layers, selectors)
• Packaging and modularity (managed 2GP vs. Unlocked packages, which are both Second-generation packaging types, LWC composition)
• Data lifecycle management (archival strategies, Flow optimization)
• Performance monitoring tools (Scale Center, Query Plan Tool, ApexGuru, Salesforce Code Analyzer)
• Build vs. buy analysis (AgentExchange evaluation)
• License and sandbox optimization
• Cost monitoring and governance (dashboards, budget controls, showback vs. chargeback models)

For Agentic Solutions: Agent workflows compound resource consumption across reasoning steps, tool calls, and data retrievals, so token usage, inference latency, and memory patterns require optimization. Agentic systems also introduce consumption-based costs (Flex Credits, inference tokens) that are harder to predict than per-user licensing. Agentic Work Units (AWUs) measure the work agents actually complete — discrete tasks accomplished — rather than raw token consumption.

To learn more, see the Resource and Cost Optimization pillar and Agentic Enterprise Resource and Cost Optimization.

Make sure that your solution is accessible, non-discriminatory, inclusive, and transparent, with appropriate human oversight of automated decisions. Fairness is built on platform foundations. Salesforce Lightning Design System (SLDS) provides built-in accessibility for standard components, while custom components require explicit WCAG 2.1 AA implementation (with WCAG 2.2 AA, the current W3C Recommendation as of December 2024, advised for new work). The pillar covers:

• Accessibility testing (axe-core, sfdx scanner)
• Non-discrimination patterns (OWD, sharing rules, FLS with Shield Event Monitoring)
• Privacy architecture (Data 360 consent management, Field Audit Trail)
• AI ethics governance (review boards, fairness gates, regulatory compliance).

For Agentic Solutions: When agents make autonomous decisions affecting people, fairness stakes increase. Explainability (understanding why an agent acted), contestability (challenging decisions), and Human-in-the-Loop (proportional oversight) become critical.

To learn more, see the Fairness pillar and Agentic Enterprise Fairness.

No pillar exists in isolation. Architectural decisions in one pillar inevitably affect others:

• Stronger Trust controls (encryption, audit logging) consume more resources and add cost (Resource and Cost Optimization) and add latency affecting Reliability
• Greater Reliability (redundancy, multi-region) increases cost (Resource and Cost Optimization) and operational complexity (Operational Excellence)
• More comprehensive Fairness enforcement (human oversight, bias monitoring) slows agent throughput (Resource and Cost Optimization)
• Higher Operational Excellence maturity (comprehensive instrumentation) enables better Trust enforcement and earlier Fairness issue detection

These interactions mean that architectural quality is always a balance. The framework helps architects understand what they are trading and make those trades intentionally. The goal is not to maximize every pillar simultaneously—it is to achieve the right quality profile for a given solution's requirements, risk tolerance, and business context.

Share your feedback on the Well-Architected Framework.