- What each of the three org strategies actually entails and what it costs to maintain
- The legitimate cases for single-org and for multi-org — not the vendor version
- The 7 questions that should determine your org strategy before any build starts
- Why the "hybrid" approach usually fails — and when it's justified
- The hidden costs of getting this decision wrong and how to surface the decision in the right forum
The Decision That Shapes Everything
Of all the architectural decisions made in a Salesforce programme, org strategy is the one that has the longest-lasting consequences and the most pressure applied to make it quickly. You'll be in an early discovery workshop, there will be a slide titled "Enterprise Salesforce Architecture" and a Salesforce logo sitting above a single cloud icon, and someone will say: "And of course, we'd recommend a single-org approach."
Nobody will challenge it. The business stakeholders don't know what it means. The Delivery Manager is focused on the programme timeline. The partner has built the commercial model around a single org. The Salesforce AE is paid on licence volume, and a single org with consolidated user counts works in their model too.
So the decision gets made by default — not by analysis. And then, two years later, someone is standing in a governance review explaining why a merger of two business units' Salesforce data is going to take 18 months and cost more than the original implementation.
This tutorial exists so you can make this decision by design.
Org strategy is a business decision that has technical implications — not a technical decision that has business implications. It should be made by business leaders with input from architects. It should not be made by architects, partners, or Salesforce without the business understanding the trade-offs.
What "Single Org" Actually Means
A single-org strategy means all business units, geographies, and functions that use Salesforce share one Salesforce organisation — one set of metadata, one database, one release cycle, one set of users and licences.
The benefits are real. Cross-business-unit reporting is straightforward because the data is in one place. A unified view of a customer across Sales, Service, and Marketing requires no integration because all three functions share the same Account and Contact records. The operations overhead is lower — one set of admins, one release process, one sandbox strategy.
But the costs are also real. One release cycle means one governance process. If the Sales team wants to deploy a change to the Opportunity object on the first Tuesday of the month and the Service team's change freeze runs until the 15th, those release cadences conflict. Every change to a shared object requires coordination across every team that uses it. This is not a technical problem — it's a political and operational one, and it scales with org complexity.
The other hidden cost of single-org is the configuration ceiling. Salesforce has limits on the number of custom objects (2,000), fields per object (500 custom), record types, page layouts, and countless other metadata components. A multi-divisional enterprise with 5-10 years of Salesforce growth can genuinely approach these limits in a single org, at which point the conversation about org architecture becomes non-optional.
What "Multiple Orgs" Actually Means
A multi-org strategy means different groups use different Salesforce organisations. This could be geographical (APAC org, EMEA org, Americas org), divisional (one org per major business unit), or functional (a Sales Cloud org separate from a Service Cloud org).
The benefits are also real. Independent release cadences. Business Unit A can deploy every sprint. Business Unit B, which is in a regulatory change freeze, can hold their org stable for three months. Neither team is blocked by the other. The data isolation is absolute — there's no risk of data cross-contamination between orgs, which matters in regulated industries and in M&A situations where two recently merged companies need to maintain separate data until legal requirements are satisfied.
The costs, however, are substantial. Shared customer data disappears. If a customer buys from Division A and calls Division B's service team, the service agent has no visibility of the purchase unless there's an integration — which there now needs to be, permanently. The integration cost is ongoing. Every time a field is added to Account in one org, the integration layer may need to be updated. This is not a one-time project cost; it's a sustained operational and maintenance cost.
There's also the licence complexity. Users who work across business units need licences in multiple orgs. Salesforce's licence model doesn't make this cheap — and in a True-Up negotiation, multiple org user counts aggregate in ways that are not always favourable.
Implementation partners almost always recommend single-org. The commercial reason is straightforward: a complex, highly-customised single org requires more configuration, more development, more integration, and more governance work — all of which they bill for. A properly scoped multi-org strategy may be architecturally correct but commercially less attractive to a partner. Ask your architect to make the case for multi-org explicitly before dismissing it.
The Hybrid: When Best of Both Becomes Worst of Both
The hybrid approach — a primary org for the core business, with satellite orgs for specific divisions or functions — appears to offer the best of both worlds. In practice, it usually doesn't.
The primary org still has all the governance overhead of a large single-org deployment. The satellite orgs still need integration with the primary org for shared customer data. You now have the integration complexity of multi-org AND the governance complexity of a large single org. The orgs that were supposed to be "independent" are still waiting for the primary org's release window to deploy changes that touch shared objects.
There are legitimate scenarios for a hybrid approach. Acquisitions are the most common: a newly acquired company has its own Salesforce org and the integration effort to merge it into the parent org's structure is not trivially justified. Running the acquired org as a satellite for 12-18 months while the business integration is worked out is reasonable. Calling that a long-term architecture is not.
The 7 Questions That Should Decide Your Org Strategy
Before any architecture diagram is drawn, these seven questions should be answered by the business — not the architect, not the partner:
1. Is there a regulatory or legal requirement for data isolation between business units? GDPR, HIPAA, FCA regulations, or jurisdictional data residency requirements may mandate that customer data from one geography or business unit cannot be co-located with another. If yes, multi-org is not optional.
2. Do different business units need genuinely independent release cadences? Not "preferred" independent releases — genuinely mandatory ones, such as a regulated division with change freeze periods that differ from the rest of the business. If yes, shared release governance in a single org will create sustained friction.
3. Is a unified customer view across all business units a strategic requirement? If your board-level priority is "know the whole customer," and you sell to and service customers across multiple divisions, single-org is architecturally advantageous. Cross-org customer data unification via integration or Data Cloud is possible but expensive.
4. What is the acquisition likelihood over the next 5 years? Acquisitions create immediate multi-org situations. If your company acquires 2-3 businesses per year, your "single org" strategy will require a constant programme of org mergers. Designing your governance model for that reality upfront is better than being surprised by it.
5. Are the business units' Salesforce processes genuinely shared or genuinely different? If two divisions have different sales processes, different service workflows, different object models — the "shared" value of single-org diminishes. The shared governance cost remains.
6. Who governs Salesforce changes across the enterprise? Single-org requires enterprise-wide governance. If your organisation does not have — and cannot build — a governance function that spans all business units, single-org will become ungovernable within three years.
7. What is the 5-year Salesforce growth trajectory? If the business plans significant expansion of Salesforce usage — new clouds, new business units, new geographies — the architecture needs to accommodate that growth. Starting multi-org when expansion is predictable is cheaper than splitting a single org later.
If you cannot point to a named individual or committee with the authority to reject a change request from a business unit's senior VP because it conflicts with another business unit's release plan — you do not have single-org governance. And without single-org governance, a single org becomes a source of conflict, not a source of value.
Making the Decision in the Right Forum
Org strategy should be on the agenda of the programme's governing body, not a slide presented by the Salesforce partner in a discovery workshop. The people who need to sign off on this decision are:
- The CTO or Head of Technology, who owns the architectural direction
- The heads of each major business unit that will use Salesforce
- Legal and compliance, if data residency or regulatory separation is a factor
- Finance, because the licence and operational costs differ materially by strategy
The decision should be documented in a formal Architecture Decision Record (ADR) with the rationale, the alternatives considered, and the conditions under which the decision would be revisited. "We chose single-org and will revisit if we acquire a business with a non-compatible Salesforce implementation" is a legitimate ADR entry. "We chose single-org because that's what Salesforce recommended" is not.
The Decision You'll Most Regret
Of the three strategies, the one that organisations most regret — in my experience — is not multi-org when single-org would have been better. It's the reverse. The single-org decision made quickly in year one, which becomes a governance nightmare by year three, and a strategic liability by year five.
The reason is the asymmetry of the problem. Moving from single-org to multi-org mid-flight requires a data migration, an integration project, a new governance model, and a period of running two orgs simultaneously. It is expensive, disruptive, and slow. Moving from multi-org to single-org is also expensive — but you control the timing, because you can maintain the status quo indefinitely while you plan the merger.
If you're in genuine doubt between single-org and multi-org, the more reversible decision is multi-org. Keep your options open. Merging orgs later is always possible. Splitting a deeply integrated single org is a programme in its own right.
Key Takeaways
- Org strategy is a business decision — it should be made in a governance forum with business leaders, not in a technical workshop with architects and partners
- Single-org wins when: unified customer data matters, cross-unit reporting is strategic, and enterprise-wide governance can be built and sustained
- Multi-org wins when: data residency requirements differ, release cadences are genuinely incompatible, or M&A creates irreconcilably different Salesforce implementations
- The hybrid approach adds complexity of both strategies without fully delivering the benefits of either — use it tactically (acquisitions), not as a permanent architecture
- The 7 questions (regulatory requirements, release independence, unified customer view, acquisition likelihood, process similarity, governance capacity, growth trajectory) are the decision framework — answer them before drawing any architecture diagrams
- When in genuine doubt, multi-org is more reversible than single-org; the cost of a later merger is real but plannable
Checkpoint: Test Your Understanding
1. A company's Legal team has confirmed that customer data from their UK and US operations cannot be stored in the same database due to regulatory requirements. What org strategy does this mandate?
2. Why do implementation partners typically recommend single-org, even in cases where multi-org may be architecturally appropriate?
3. If an organisation is genuinely uncertain between single-org and multi-org, which approach is more reversible if the decision turns out to be wrong?
Discussion & Feedback