Salesforce architecture is the way the Salesforce Platform is built: a multitenant, metadata-driven cloud system where many companies share the same infrastructure and code, while each company's data and configuration stay separate. On top of the Hyperforce infrastructure sit layers for data, AI, automation, user interface and APIs, and every Salesforce app, from Sales Cloud to your own custom objects, runs on those layers.
This post was first published in 2020 as "Explanation About Salesforce Architecture". It has been rewritten for 2026 to cover Hyperforce, Data 360 and Agentforce, the Well-Architected framework and what a Salesforce architect actually does.
What is multitenant architecture?
Trailhead's architecture unit compares Salesforce to an apartment building: each company has its own private space, but everyone shares the building's resources. Every customer gets the same computing power, storage and core features whatever its size, and upgrades arrive automatically. You never install software or manage servers.
Sharing has a consequence developers meet quickly: governor limits. Each transaction is capped on queries, records and CPU time so that one tenant can't slow the others. Our governor limits guide covers them.
Why is Salesforce called metadata-driven?
Metadata is "data about data": the objects, fields, page layouts, security settings, flows and code that make up your org. When you create a custom object, Salesforce does not create a new physical database table. Its multitenant architecture guide explains that the platform stores the definition as metadata and uses it at runtime to produce your application, with each org's data partitioned so queries only touch that org.
That design is why you can add a field in seconds without downtime, why every customisation is available through APIs, and why your configuration survives upgrades. Trailhead notes that all data and metadata is API enabled: every object and field gets an API name usable in pages, flows, email templates and integrations.
The layers of the Salesforce Platform
The Salesforce Platform has seven layers, from Hyperforce infrastructure at the bottom to the apps users see at the top. Salesforce's architects describe the current platform as a stack of layers, each built on the one below, in The Salesforce Platform, Transformed for Tomorrow:
| Layer | What it includes | Why it matters to you |
|---|---|---|
| Infrastructure | Hyperforce on public cloud providers, organised in cells; zero-trust controls and encryption in transit and at rest | Data residency choices and resilience come from here |
| Metadata and Core | The Core runtime, the single system of record for application metadata; a layered extension model for Salesforce, ISVs, admins and users | Your customisations and installed packages coexist without overwriting each other |
| Data | SalesforceDB, a multitenant transactional database that extends PostgreSQL; Data 360 for big data, a lakehouse and zero-copy federation; search | Where your records live and how external data is unified |
| AI | Agentforce, the Agentforce Trust Layer (masking, guardrails, grounding; available in select use cases as of November 2026), Agentforce Studio | AI agents act on your data under your security model |
| App platform and automation | Flow (record-triggered, scheduled, screen, orchestrator), Apex, Lightning Web Stack for UI, packaging | Low-code and pro-code tools for building business logic |
| APIs and integration | An API-first portfolio, MuleSoft, data connectors, event streams exposed as Platform Events | Everything in the UI can be reached by other systems |
| Apps | Sales Cloud, Service Cloud, industry clouds, AgentExchange (formerly AppExchange) apps and custom apps | What users actually see |
One detail ties the layers together: the record save order of execution, which keeps logic from Salesforce, packages and your own team predictable. See our order of execution guide.
How security fits into the architecture
Trust runs through every layer. At infrastructure level, the platform guide says traffic is protected with TLS, stored data with a key management system backed by hardware security modules, and each tenant gets its own encryption key. At application level, you control access in three places: who can log in, which objects and fields each user can see, and which records they can reach through org-wide defaults, roles and sharing rules. The same permissions apply to API calls. For AI, Trailhead describes a trust layer that adds guardrails so generative AI can use company and customer data safely. For day-to-day controls, see our Salesforce security guide.
Designing a good Salesforce solution: Well-Architected
A good Salesforce design is one that balances trust, reliability, operations, cost and fairness, which is what Salesforce's own framework measures. Salesforce publishes the Well-Architected framework to help architects weigh trade-offs. It has five pillars:
- Trust: secure, compliant design that keeps people, data and systems safe.
- Reliability: systems that keep working and recover when something fails.
- Operational Excellence: monitoring, automation and continuous improvement.
- Resource and Cost Optimization: deliberate investment for long-term value.
- Fairness: systems that are transparent, accessible and equitable.
In practice, most architecture decisions in a Salesforce project fall into a handful of areas:
- Data model: standard objects before custom ones; lookup or master-detail; how many records each object will hold.
- Sharing: the most restrictive org-wide defaults that work, then open up access.
- Automation: one approach per object, Flow first and Apex where Flow can't cope, all bulk-safe.
- Integration: choose the pattern before the tool. Salesforce's integration patterns are request and reply, fire and forget, batch data synchronization, remote call-in, UI update based on data changes, and data virtualization.
- Environments: a sandbox chain and source control so changes move one way to production; see our sandbox guide and DevOps guide.
- Org strategy: one org or several. Multiple orgs isolate business units but duplicate data and effort; consolidation is a common later project.
Common architecture mistakes
Most architecture problems are shortcuts taken at go-live that become expensive later.
- Custom objects that copy standard ones. A custom "Client" object instead of Account loses built-in features and compatibility with AgentExchange apps. See our Salesforce data model guide.
- Several automation tools on one object. Triggers, flows and legacy rules firing in an unknown order cause recursion and limit errors. Our Apex trigger guide explains the one-entry-point rule.
- Public read/write by default. Easy at go-live, hard to tighten once users depend on it.
- Point-to-point integrations everywhere. Each new system adds connections to maintain; an integration layer scales better.
- Ignoring data volume. Millions of records on one object, or one account owning most of them, cause locking and slow queries.
What does a Salesforce architect do?
A Salesforce architect designs how an org fits together and is accountable for the trade-offs. Much of the search interest in "Salesforce architecture" is about these people. A Salesforce architect owns the decisions above: data model, sharing, integration, automation, environments and release process, and the trade-offs between them. Typical titles are solution architect (business fit across clouds), technical architect (platform design and limits), integration architect, data architect and enterprise architect (how Salesforce fits the wider company landscape). Admins and developers usually grow into the role.
Do architects need to code? They need to read code and know what Apex, Lightning Web Components and the APIs can and cannot do, but the job is mostly design, documentation and decisions: data model diagrams, integration designs, sharing models and release plans, agreed with business owners. The core skills are platform depth, communication and the ability to explain a trade-off to a non-technical sponsor. Hiring for the role? Our Salesforce interview questions include architecture topics.
The top credential is Salesforce Certified Technical Architect. As of November 2026 its Trailhead page lists the System Architect and Application Architect credentials as prerequisites, then two steps: an online Architect Review Board Evaluation and the Architect Review Board Exam, in which candidates design, present and defend a solution to a detailed scenario. Salesforce's Architects site, architect.salesforce.com, hosts the diagrams, decision guides and Well-Architected material architects use daily.
Getting help
Techila is a Salesforce Summit Partner. Our Salesforce consulting services team reviews org architecture and designs new solutions, and our org consolidation service handles multi-org strategy. Talk to us about an architecture review.
Frequently asked questions
What is Salesforce architecture?
It is the way the Salesforce Platform is built: a multitenant, metadata-driven system where many customers share infrastructure and each org's configuration is stored as metadata. Layers for data, AI, automation, user interface and APIs sit on top of the Hyperforce infrastructure, and apps such as Sales Cloud are built on the platform.
What does multitenant mean in Salesforce?
Many customer orgs share the same infrastructure and code base while their data and configuration stay separate, like flats in one apartment building. Everyone gets the same features and upgrades automatically, and Salesforce enforces per-transaction limits so no tenant can starve the others.
What is metadata in Salesforce?
Metadata is data about data: the structure and configuration of your org, such as objects, fields, page layouts, security settings, flows and code. When you create a custom object, the platform stores its definition as metadata rather than creating a new physical database table.
What is Hyperforce?
Hyperforce is the infrastructure Salesforce now runs on: public cloud providers instead of Salesforce's own data centres. Salesforce's architecture guide describes it in cells, each a scale unit and a boundary that limits the blast radius of failures.
What does a Salesforce architect do?
A Salesforce architect designs how a business's Salesforce solution fits together: data model, security and sharing, integrations, automation, environments and release process, and the trade-offs between them. The top credential is Salesforce Certified Technical Architect, awarded after a review board.