Understanding Salesforce Org Strategy: The Decision Most Organisations Never Make
Most organisations never consciously choose a Salesforce org model. They buy Salesforce, and the structure accumulates. A business unit signs a contract. Another one does the same a year later. By the time anyone asks the question — single org, multi-org, or something in between — the answer has already been partially decided by a series of purchases nobody was thinking of as an architectural decision at the time.
This article is for organisations that want to make the choice deliberately, before events make it for them. It explains what each model actually is, what it genuinely costs, what each one looks like when it goes wrong, and how to figure out which one is right for your situation. It is also useful if you're already living with the consequences of a choice that was never really made — because understanding the models clearly is the prerequisite to doing anything about them.
What a Salesforce org actually is
Before the models make sense, the terminology needs to. A Salesforce org — short for organisation — is a single instance of the Salesforce platform configured to serve a particular business need. Think of it as a self-contained environment: its own data, its own configuration, its own users, its own customisations.
The important thing to understand is that Salesforce itself is a single platform — one piece of software, running at scale, serving millions of customers. What each customer gets is their own instance of that platform, walled off from everyone else's. That instance is the org. Within a single org, multiple business applications can coexist — a sales team using Sales Cloud, a service team using Service Cloud, a marketing function running Marketing Cloud — all operating within the same environment, sharing the same data model and the same user base.
That sharing is both the primary advantage of a single org and the source of its primary complexity. Which is exactly what the three models are really about.
The three models
Single org is what it sounds like: everything in one place. All business units, all applications, all users operating within a single Salesforce instance. One contract, one set of data, one governance model, one relationship with Salesforce. Architecturally, it is the cleanest solution. Data is consistent by default. Users have one login. Reporting spans the entire organisation without requiring integration. It is the model architects tend to prefer, and for good reason — it is the most technically coherent.
It's worth being explicit about something buyers often get wrong here: a single org does not mean a single application. Sales Cloud, Service Cloud, Field Service, Marketing Cloud, a custom case management application, and more can all coexist within one org simultaneously. Each serves its own function, its own users, its own process — but they share the same underlying data model and the same Salesforce instance. The assumption that separate products require separate orgs is common and almost always incorrect. It's also an assumption that, if acted on, creates the multi-org problem before the organisation has had a chance to consider whether it wants one.
Multi-org is the opposite: separate Salesforce instances for separate business units or functions, each running independently. Each org has its own contract, its own data, its own users, its own admin team. Business units operate autonomously. There is no shared environment and no inherent data connection between the orgs. It is messier architecturally, but it reflects the operational reality of many organisations — business units that are genuinely separate, with genuinely different needs and genuinely different processes.
Hybrid sits between the two, and is best understood through the model that makes it most concrete: hub and spoke. A large central org — the hub — serves the core enterprise. Smaller, simpler orgs — the spokes — serve subsidiary units, regional operations, or distinct business functions. Those spoke orgs typically handle a narrower set of activities and replicate relevant data back to the hub, which maintains the consolidated view.
A multinational with significant regional operations illustrates this well. The central org carries the full weight of the enterprise — complex data models, deep integrations, sophisticated reporting. A regional spoke might be doing a much simpler job: recording sales activity in a single market and surfacing it back to headquarters. The spoke doesn't need the complexity of the hub. It just needs to do its own job cleanly and keep the hub informed.
Hybrid models work well when the operational difference between the hub and the spokes is real and structural, not just political. When it's the latter — when spokes exist because business units resisted consolidation rather than because they genuinely needed separation — the model tends to carry the costs of both single and multi-org without the full benefits of either.
The cost question — and why the obvious answer is wrong
Single org is generally assumed to be cheaper. One contract, consolidated licensing, a single renewal conversation. The logic is straightforward.
The reality is more complicated, and the complication matters.
When an organisation consolidates multiple orgs into one, it doesn't simply merge the contracts. It has to accommodate everything that was spread across those orgs — every function, every requirement, every edge case. The problem is that some of those requirements are niche. One org might have needed a specific security feature to meet compliance obligations. Another might have required a capability that only one team actually uses. In a multi-org environment, those costs stay contained — only the org that needs the feature pays for it.
In a single org, everything is enterprise-wide. If one function requires a particular licensing tier or a specific add-on, the entire organisation moves to that tier or pays for that add-on. The feature cost that was previously confined to one business unit becomes a cost applied across every user in the environment. That uplift can be significant — significant enough, in some cases, to make consolidation more expensive than the multi-org arrangement it replaced.
Security and data privacy are a particular case in point. Multi-org provides natural data separation — business units that handle sensitive data can be isolated from those that don't, by virtue of operating in entirely separate environments. In a single org, achieving the same separation requires careful architectural work. It's possible, but it adds complexity and, often, additional licensing.
None of this means single org is the wrong answer. It frequently is the right answer. But the cost assumption — that consolidation automatically saves money — deserves scrutiny before it drives a decision.
What each model looks like when it works
Every model has a version that works well. Understanding what that looks like is as important as knowing what to avoid.
Single org done well delivers on its core promise: one source of truth across the entire organisation. Users log in once. Data is consistent without integration. Reporting spans every function without reconciliation. When a mature organisation with strong governance adopts this model, the commercial benefits compound over time — one contract to manage, one renewal conversation, one platform roadmap. The Salesforce relationship operates at an enterprise level rather than being fragmented across multiple account teams and contract cycles. For organisations that genuinely have this maturity, single org is architecturally and commercially superior.
Multi-org done well reflects operational reality honestly. In a conglomerate with genuinely separate business units — different customers, different processes, different compliance environments — forcing everything into one org creates artificial complexity in the name of architectural purity. Separate orgs give each business unit the autonomy to move at its own pace, govern its own data, and manage its own roadmap without waiting for the queue to clear. When the business units genuinely have little reason to interact, multi-org is not a consolation prize — it is the right answer.
Hybrid done well is the hub-and-spoke model operating as designed: a central org carrying enterprise complexity, with spoke orgs that are deliberately simple and tightly scoped. The spokes do their job cleanly, replicate what the hub needs, and don't accumulate the customisation and governance overhead of a full org. The boundaries between hub and spokes are explicit and maintained. For organisations with a clear enterprise core and genuinely distinct regional or subsidiary operations, this model balances central visibility with local agility in a way neither single nor multi-org can fully achieve.
What each model looks like when it goes wrong
Every model also has a failure mode. Knowing what they look like in practice is at least as useful as knowing what the models are supposed to achieve.
Single org done badly slows everything down. In a multi-org environment, a business unit that owns its own instance can make changes on its own timeline. A new field, a process update, a report — the admin makes it happen. In a single org, that same change has to go through a shared governance process alongside every other change every other business unit wants to make. The queue gets long. The pace drops. Business units that were used to moving quickly find themselves waiting. If the governance model and change management discipline aren't genuinely strong before consolidation happens, they are not going to emerge from it — they will simply be exposed by it.
Multi-org done badly is the accumulation problem described in the article that follows this one. But there is a specific commercial failure mode worth naming here: the per-user licence trap. A user who needs to work across three orgs in a multi-org environment needs three separate licences — one in each org. Three logins. Three sets of access to manage. Three contract line items. The work is the same. The cost is three times what it would be in a single-org environment. At individual-user scale, that's manageable. At organisational scale, it compounds.
Hybrid done badly tends to inherit the failure modes of both. Spoke orgs that have drifted too far from the hub create the same integration and data consistency problems as unmanaged multi-org. A hub that has grown too large and complex creates the same change management bottlenecks as a poorly governed single org. The hub-and-spoke model requires clarity about what belongs in the hub and what belongs in the spokes — and the discipline to maintain that distinction over time. Without it, the model gradually collapses into one of the other two by default.
Three questions that drive the decision
Frameworks for this decision exist — Salesforce has published guidance, and most serious consultancies have their own version. But at the core of most of them, the decision comes down to just three questions. Answer these honestly and you're well on your way to knowing which model fits:
- Are the users the same across the actual or proposed Salesforce orgs?
- Is the data the same across the actual or proposed Salesforce orgs?
- Are the integrations the same across the actual or proposed Salesforce orgs?
If users, data, and integrations are substantially shared across the organisation, a single org is likely the right model — you're not gaining meaningful separation by splitting them, you're just adding complexity. If users, data, and integrations are genuinely distinct across business units, multi-org or hybrid reflects the operational reality more accurately than forcing everything into one environment.
The answers are rarely all yes or all no. Most organisations sit somewhere in between. The questions are not a formula — they are a starting point for an honest conversation about what the organisation actually looks like, as distinct from what it would like to look like on a whiteboard.
The question underneath the questions: are you mature enough?
The three questions above tell you what model is technically correct for your organisation. But there is a prerequisite that sits underneath all of them, and it matters more than most organisations want to acknowledge: is your organisation mature enough to operate the model the answers point to?
This is not a soft consideration. It is a hard one.
A single org demands strong governance, strong change management, and a genuine capacity for cross-business-unit collaboration. It requires an organisation where different teams can agree on shared processes, accept shared timelines, and operate within a shared platform discipline. Where those things exist, single org delivers on its promise. Where they don't, it doesn't matter how technically correct the answer is — the model will punish the organisation for the maturity gap. The change queue lengthens, frustration builds, and the business units that were most resistant to consolidation find their scepticism confirmed.
The honest advice for organisations that recognise themselves in that description is not "get more mature and then do single org." It is to accept, without embarrassment, that multi-org or hybrid is the right answer for where the organisation is now. Those models are not a failure state. They are an accurate reflection of operational reality. An organisation that chooses multi-org because its business units are genuinely distinct and its governance is genuinely decentralised is making a sound decision. An organisation that chooses single org because it sounds better on a whiteboard, without the maturity to support it, is setting itself up for a different kind of problem.
The model has to fit the organisation. Not the other way around.
Why earlier is better — and which direction is easier
The single most important thing to understand about this decision is that it gets harder to reverse in one direction than the other.
Starting with a single org and later spinning out a spoke or creating a separate instance for a business unit that genuinely needs independence is a manageable process. The data is in one place, the contracts are consolidated, and the architectural starting point is clean. Separating is complex, but it is tractable.
Starting with multiple orgs and attempting to consolidate into a single org — or even into a well-governed hybrid — is significantly harder. Data has diverged. Customisations have accumulated independently. Contracts are misaligned. Business units have developed a sense of ownership over their instances that creates political resistance to consolidation that can be as difficult as the technical work itself. The effort required is of a different order.
If you are at the beginning of your Salesforce journey — or advising an organisation that is — the practical guidance is to start with the single-org model and treat any future separation as an explicit decision requiring justification, rather than allowing multi-org to happen by default.
What happens when it does happen by default is the subject of the next article in this series.
Mike Roberts spent over eight years at Salesforce, including time as a Strategic Account Director, before founding Aequus Consulting. He works with New Zealand organisations on Salesforce licence optimisation and renewal preparation, with no vendor affiliations.