One Salesforce org or several? How to choose for your company

Default to a single Salesforce org when your business units, regions or brands serve overlapping customers or need one view of revenue. Choose several orgs only when a hard constraint forces it: legal separation, data residency, truly unrelated processes, or release calendars that cannot coexist. Every extra org adds integration, admin and reporting work that never goes away, so the bar for splitting should be high.

Why does the number of orgs matter so much?

The org count sets where customer data lives, who can change it and how fast. It is the most expensive architecture choice to reverse later.

An org is a separate database, security model, metadata set and release pipeline. Two orgs means two of each. Shared customers become duplicated customers unless you build something to reconcile them. A single org avoids that, but asks every unit to agree on objects, fields, picklists and the order in which changes ship. Neither option is free. The question is which cost your company is better equipped to carry.

Which signals point toward one org?

Shared customers and a shared leadership view are the strongest signals. If the same account buys from two divisions, one org usually wins.

• Sellers from different units call on the same buying committees, and someone needs to see all of that activity together.
• Leadership wants one forecast, one renewal book or one service backlog across brands.
• Units sell similar products through similar stages, even if their terminology differs.
• Service teams hand cases between regions or follow the sun across time zones.
• Your admin and developer bench is small, so duplicated platform work would stretch it thin.
• Integrations to ERP, billing or marketing tools would otherwise be built and maintained twice.

A single org also makes cross-sell visible. Account teams can see what a customer already owns before they pitch the next thing.

Which signals justify running separate orgs?

Separation is justified by constraints that configuration inside one org cannot meet. Preference or politics alone rarely qualifies.

• Regulation or contract terms require data for one entity to be physically and administratively isolated from another.
• Data residency rules require records to stay in a particular region, and a single instance location cannot satisfy every jurisdiction.
• Business units share no customers, no products and no sellers, and leadership only needs summary figures.
• One unit is likely to be divested, and a clean carve-out matters more than integration today.
• Release needs genuinely conflict, such as a regulated unit that must validate every change while another ships weekly.
• Data volumes or customization in one unit would push shared platform limits for everyone else.

How do the criteria compare side by side?

Score each criterion honestly against your own operating model. The table shows which way each one usually leans.

If most rows land in the left column, start from one org. If one row lands firmly on the right for a legal reason, that row can outweigh the rest.

What does a single org cost in governance and sharing?

You pay with design discipline. A single org needs a sharing model, naming rules and a change process that every unit accepts.

Expect a role hierarchy and sharing rules shaped around several business units. Where units must not see each other's records, add restriction rules or team-based access. Record types and page layouts multiply as units ask for variations, and each one adds testing effort. Large sharing changes can trigger long recalculations when data volumes are high. Most of all, someone must be empowered to say no. Without a design authority, a shared org slowly fills with near-duplicate fields and competing automation.

A practical rule: share the core objects and definitions, and let units differ only in layouts, record types and approval steps. Write that rule down before the second unit goes live.

What do multiple orgs cost in integration and administration?

You pay with duplicated effort and permanent integration. Each org needs its own admins, release pipeline, security reviews and license management.

• Every integration to ERP, finance or marketing is built once per org, or routed through middleware that you then maintain.
• Customers who appear in more than one org need matching rules and a master record somewhere.
• Cross-org reporting needs a warehouse, a reporting tool or a data platform, plus agreed definitions.
• Security patches, seasonal release testing and permission audits repeat in each org.
• Users who work across units need several logins and often several licenses.

None of this is unusual, but it should be budgeted as a standing cost, not a one-off project line.

Which multi-org patterns actually work?

Hub-and-spoke is the most common durable pattern. One hub org holds shared customers and reporting, and spoke orgs run unit-specific processes.

In hub-and-spoke, the hub owns the golden account and contact records and the company-wide view. Spokes publish key events, such as a closed deal or a new case, to the hub through middleware or platform events. Spokes read shared reference data back from the hub rather than keeping their own copies. The pattern works when ownership of each object is written down. It fails when two orgs both believe they master the same account.

For lighter data sharing, Salesforce Connect with its cross-org adapter can show another org's records as external objects without copying them. The older Salesforce to Salesforce feature still exists in some orgs. It dates from Classic, and most architects now prefer Connect or an API layer. Check current availability and licensing for both with your account team.

For a unified customer profile across orgs, Data Cloud, now branded Data 360, can ingest data from several orgs and resolve identities into one profile. Salesforce has introduced options for sharing that unified data back to connected orgs. Packaging and setup change often, so treat any specific feature as something to confirm before you design around it. Our guide to when Data 360 is worth it covers the prerequisites.

What does good multi-org governance look like?

Central standards with local delivery. A small enterprise team owns shared definitions, security baselines and integration contracts, while unit teams build within them.

• A design authority that approves new objects, shared fields and integrations across every org.
• One data dictionary covering account, contact, product and revenue definitions used in every org.
• A shared security baseline: MFA, permission-set conventions, integration user rules and audit cadence.
• Common deployment tooling and source control, even when each org releases on its own schedule.
• A published owner for each org, with a named escalation path when orgs disagree.
• An annual review asking whether any org should now be merged or retired.

Enterprises that run many orgs well give this governance its own team. It should not be a side duty for the busiest admin. Our release management guide covers the pipeline side.

What does one org serving several regions look like in practice?

Abstrakt's multi-region technology-services case study shows one Sales Cloud org handling several entities, currencies and markets.

The IT and cybersecurity company operated across North America and the Middle East and had just moved to Enterprise edition. Its accounts were arranged so location revenue summed into each parent company. A single product catalog sat behind distinct US and Middle East price books, with both recurring and one-time products. Profiles, roles and sharing were aligned to the organization. Everything went live inside a 20-hour Jumpstart, and the org reached a 98% health-check score. Regional pricing and entity structure were handled with configuration in one org, without a second instance.

How do you move from many orgs to one?

Treat it as a staged consolidation, one unit or process at a time, after choosing a surviving org. The mechanics match an acquisition merge.

Before any migration, agree the target data model, the sharing design for combined units and the order in which units move. The detailed reconciliation steps for data, users, automation and integrations are covered in the acquisition merge guide linked below. The same sequence applies when the orgs are your own, not a target's.

When is splitting an existing org the right call?

Rarely, and usually because of a legal or ownership event. A planned divestiture, a new regulator or a residency mandate are the usual triggers.

Splitting means cloning metadata, separating records by ownership or business unit, and rebuilding integrations for the new org. Shared customers are the hardest part, because each side must decide what it keeps. If the trigger is frustration with a crowded change queue, fix governance first. A split will not repair a missing design authority.

Which mistakes do architects make most often?

Most mistakes come from deciding by org chart rather than by customer and process.

• Creating an org per business unit because each unit has its own leader, then building integrations to recover a combined view.
• Merging into one org without a design authority, so each unit adds its own version of status, region and segment.
• Citing data residency as a reason to split without checking what hosting options the contract already provides.
• Assuming cross-org data sharing tools remove the need for a master record decision.
• Leaving acquired orgs running with no review date, until the integration estate costs more than consolidation would have.
• Ignoring licensing: users who need access in several orgs may need several licenses.