Determining Your Salesforce Org Strategy

Part 102: Determining Your Salesforce Org Strategy

Welcome back to the Salesforce series. If you have been following along with our architecture discussions, you know that most design decisions in Salesforce come down to trade-offs. Nowhere is that more true than the org strategy question: should your company run one Salesforce org or multiple? This decision is deceptively simple on the surface, but it has deep implications for cost, compliance, data access, integration complexity, and your team’s ability to move fast.

In this post we will break down the factors that matter, walk through the pros and cons of each approach, look at real-world scenarios where one strategy wins over the other, and discuss how Salesforce Connect can act as a bridge when neither extreme is the right answer.

Why Org Strategy Matters

Your Salesforce org strategy is a foundational architectural decision. It is not something you change easily after go-live. Merging two orgs into one is a painful, multi-month project. Splitting one org into two is equally expensive. Getting this right early — or at least understanding the trade-offs before you commit — saves enormous time and money down the road.

Think of it this way: the org is the outermost boundary of your Salesforce data and configuration. Everything inside an org — objects, records, users, automation, security settings — shares a common namespace. Everything outside the org is foreign territory that requires integration to reach. Where you draw that boundary determines how your business operates in Salesforce for years to come.

The Single Org Approach

A single org means your entire company, across all business units, geographies, and product lines, operates inside one Salesforce instance. This is the approach Salesforce itself recommends as the default starting point, and for good reason.

Advantages of a Single Org

Unified data model. When all your data lives in one org, reporting is straightforward. A VP of Sales can pull a dashboard that spans every region and product line without integrating anything. Cross-selling opportunities surface naturally because reps can see what other teams have sold to the same account.

Simpler administration. You have one set of profiles, one set of permission sets, one set of sharing rules. Automation that needs to span business units — say, a lead routing flow that assigns leads based on product interest — works natively without middleware.

Lower licensing cost. You only need one set of platform licenses. Users who need access to multiple business units do not need multiple logins or multiple license seats. Features like Einstein Analytics, Flow Orchestrator, or Shield Encryption are purchased once and applied globally.

Easier integration. External systems only need to connect to one Salesforce endpoint. Your ERP talks to one org. Your marketing automation platform syncs with one org. Your identity provider manages SSO for one org.

Consistent user experience. Users learn one system, one set of page layouts, one app navigation structure. Training is simpler. Support tickets are easier to resolve because there is one environment to troubleshoot.

Disadvantages of a Single Org

Governor limits are shared. Every business unit competes for the same API call limits, storage limits, and processing limits. If one team runs a poorly written batch job that consumes all the API calls, everyone else is affected.

Release management complexity. When multiple teams build in the same org, their deployments can conflict. A change to a shared object by Team A might break Team B’s automation. You need strong governance, a well-defined branching strategy, and thorough regression testing.

Data visibility challenges. Even with sharing rules, role hierarchies, and record-level security, keeping business unit data truly separate within a single org takes careful planning. One misconfigured sharing rule can expose sensitive records to the wrong group.

Customization sprawl. Over time, a single org that serves many teams accumulates custom fields, page layouts, validation rules, and flows at an alarming rate. The Account object ends up with 300 fields, half of which only matter to one team. Technical debt compounds.

The Multi-Org Approach

A multi-org strategy means you spin up separate Salesforce instances for different parts of the business. Each org has its own data, its own configuration, and its own administrator team.

Advantages of Multiple Orgs

Hard data isolation. If your business requires that certain data never coexist in the same system — perhaps due to regulatory requirements, acquisition structures, or contractual obligations — separate orgs provide the strongest possible boundary. No sharing rule misconfiguration can leak data across orgs because the data simply does not exist in the same database.

Independent release cycles. Each org can deploy on its own schedule. Team A can push a major release on Monday without worrying about breaking Team B’s flows. This is especially valuable when business units move at different speeds or have different risk tolerances.

Governor limit isolation. Each org gets its own set of API limits, storage allocation, and processing capacity. A runaway batch job in one org does not affect another.

Tailored configuration. Each org can be optimized for its specific business process without compromise. The Sales org can have a lean, fast Account page layout while the Service org has a detailed, field-heavy layout. No one has to accommodate fields they will never use.

Acquisition friendly. When your company acquires another business that already uses Salesforce, you can keep their org running independently while you figure out the long-term integration plan. This avoids the rush to merge systems during an already chaotic acquisition period.

Disadvantages of Multiple Orgs

No unified reporting. You cannot build a single dashboard that spans multiple orgs without an integration layer. Executives who want a holistic view of the business need a data warehouse, a BI tool like Tableau, or a middleware solution to aggregate data.

Higher total cost. Each org needs its own licenses, its own storage, its own add-on features. If you want Shield Encryption in both orgs, you pay twice. Admin headcount increases because each org needs dedicated support.

Integration burden. If business units need to share any data — customer accounts, product catalogs, pricing — you must build and maintain integrations between the orgs. This means middleware, API development, error handling, and ongoing monitoring.

Duplicate data management. The same customer might exist in two orgs. Keeping those records in sync — names, addresses, ownership — is a perpetual challenge. Without a master data management strategy, your data quality degrades over time.

User friction. Employees who work across business units need to log in to multiple systems. They have multiple browser tabs, multiple sets of bookmarks, and multiple places to search for information. This is a worse user experience than it sounds, especially for leadership.

Key Factors for Making the Decision

There is no universal right answer. The correct org strategy depends on your specific circumstances. Here are the factors I weigh most heavily when advising on this decision.

Regulatory and Compliance Requirements

This is often the deciding factor. If you operate in industries like healthcare, financial services, or government, you may have regulations that mandate data residency in specific geographies, strict separation between business lines, or audit trails that cannot be commingled. GDPR, HIPAA, FedRAMP, and SOX all have implications for how data is stored and who can access it.

If a regulation requires that data from Business Unit A cannot physically reside in the same system as data from Business Unit B, you need separate orgs. Period. No amount of sharing rule configuration provides the same guarantee as a hard org boundary.

Business Unit Independence

How independently do your business units operate? If they share customers, share products, and collaborate on deals, a single org makes sense. If they are essentially separate companies that happen to share a parent — different customers, different sales motions, different service models — the argument for separate orgs gets stronger.

I have seen companies try to force unrelated business units into one org for the sake of a unified view. The result is usually a bloated, slow, hard-to-maintain system that makes nobody happy. If the business units do not naturally share data, do not force them to share an org.

Cost Tolerance

Multi-org is more expensive in almost every dimension: licensing, administration, integration, and tooling. If your budget is tight, a single org with strong security configuration is usually the more pragmatic choice. The cost difference is not trivial — doubling your org count roughly doubles your platform spend before you even factor in the integration work.

Team Size and Maturity

A single org with strong governance works well when you have an experienced Salesforce team that can enforce coding standards, manage deployments carefully, and maintain clean architecture. If your admin team is small or inexperienced, a single org with loose governance quickly becomes a mess.

Conversely, a multi-org strategy only works if you have enough admin capacity to support each org independently. Running two orgs with one part-time admin is a recipe for one well-maintained org and one neglected org.

Growth and M&A Strategy

If your company frequently acquires other businesses, plan for a multi-org reality. You will inherit Salesforce orgs through acquisitions whether you like it or not. Having a playbook for multi-org coexistence and eventual consolidation is more realistic than assuming every acquisition will immediately merge into your primary org.

When Salesforce Connect Bridges the Gap

Salesforce Connect is a feature that lets you access data from external systems — including other Salesforce orgs — without copying it into your org. It uses a concept called external objects, which look and behave like regular Salesforce objects but pull data on demand from an external source via OData or the Salesforce-to-Salesforce adapter.

How Salesforce Connect Helps with Multi-Org

If you have two orgs that need to share data but do not want to merge, Salesforce Connect lets users in Org A see records from Org B without replication. The data stays in its source org. There is no sync job to maintain, no duplicate records to reconcile.

This is particularly useful for scenarios like:

Shared customer views. A service team in Org B can see a customer’s sales history from Org A without that data being copied over.
Cross-org reporting. While you cannot build native cross-object reports on external objects in the same way as standard objects, you can display related data on record pages and use it in list views.
Acquisition integration. During the transition period after an acquisition, Salesforce Connect gives users a window into the acquired company’s data while you plan the long-term consolidation.

Limitations to Keep in Mind

Salesforce Connect is not a magic solution. External objects have real constraints. You cannot use them in all the same ways you use standard or custom objects. Specifically:

No triggers on external objects. You cannot write Apex triggers that fire when an external object record is accessed or modified.
Limited SOQL support. You cannot use all SOQL features with external objects. Aggregate queries, for example, are restricted.
Latency. Every time a user views an external object record, Salesforce makes a callout to the source system. If that system is slow or unavailable, the user sees errors or delays.
API consumption. Each external object query consumes API calls against the source org. In high-volume scenarios, this can push you toward API limit issues.
Licensing cost. Salesforce Connect is an add-on license, priced per external object or per user depending on the edition. It is not free.

Despite these limitations, Salesforce Connect is often the right middle ground for organizations that want some cross-org visibility without the overhead of a full integration layer or the disruption of an org merge.

A Decision Framework

When I work with clients on this decision, I use a simple framework:

Start with one org as the default. The single org approach is simpler, cheaper, and easier to manage. You need a compelling reason to go multi-org, not the other way around.
Check for hard requirements. Is there a regulatory, contractual, or legal reason that data must be physically separated? If yes, go multi-org for the affected business units.
Evaluate business unit overlap. If business units share customers, products, or processes, keep them in one org. If they are operationally independent, consider separate orgs.
Assess team capacity. Do you have enough admin and developer resources to support multiple orgs? If not, a single org with strong governance is the safer bet.
Plan for the future. If M&A is part of your growth strategy, build your architecture and your team’s skills to handle multi-org scenarios even if you start with one.
Use Salesforce Connect as a bridge. When two orgs need limited data sharing, Salesforce Connect can provide it without the cost and complexity of full integration or consolidation.

Section Notes

The single org approach is the recommended default for most organizations. Deviate only when you have a clear, defensible reason.
Regulatory and compliance requirements are the most common driver for multi-org. Do not underestimate the complexity of keeping data truly separate within a single org when regulations demand it.
Salesforce Connect is a powerful tool for cross-org data access, but it comes with real limitations around triggers, SOQL, and latency. Test it thoroughly before committing to it as your primary cross-org strategy.
Org merges and org splits are among the most expensive and disruptive Salesforce projects you can undertake. Invest the time upfront to get this decision right.
If you are inheriting a multi-org landscape through acquisitions, resist the urge to rush consolidation. Run the orgs independently, use Salesforce Connect for quick wins, and plan the consolidation as a deliberate, phased project.
Document your org strategy decision and the reasoning behind it. Two years from now, when a new VP asks why you have two orgs instead of one, you want a written rationale, not tribal knowledge.

In the next installment, we will continue our architecture deep dive by looking at integration patterns — how to connect Salesforce with the rest of your enterprise systems regardless of whether you are running one org or ten.