Multi-org means running Salesforce in more than one connected production org — typically because of acquisitions, regulatory requirements, or business unit autonomy. The decision is heavy because consolidation is hard and divergence multiplies maintenance work.
When multi-org makes sense:
- Regulatory walls — financial services where one division can't share data with another by law.
- Geographic data residency — EU data must stay in an EU-region org; US data in a US-region org.
- M&A — newly acquired companies on their own Salesforce that aren't worth migrating.
- Independent divisions — autonomous business units with totally different processes.
When NOT multi-org:
- "Different teams want different things" — that's solved with Record Types, Apps, and proper sharing.
- Cost: you're paying for Salesforce twice (or more), plus integration costs.
If you do go multi-org:
- Master the data model — define the canonical schema you want shared. Decide which objects sync (Accounts, Products, Pricebooks) vs which stay local (Cases, internal Tasks).
- Hub + spoke or mesh? — one central org as the source of truth (hub) with subsidiaries pulling from it, or peer-to-peer? Hub-and-spoke is simpler to govern.
- Integration layer:
- Salesforce Connect — exposes external objects as virtual tables. Real-time, no copy. Best for read-only views of the hub from spokes.
- Salesforce-to-Salesforce (S2S) — built-in cross-org connector. Limited but free. Better for low-volume sharing.
- Mulesoft or middleware — for any meaningful integration volume. Hub-and-spoke flows through Mulesoft as the orchestrator.
- Replication via change data capture or Platform Events — for near-real-time sync.
- Identity strategy — single SSO IdP across all orgs (Okta/Azure AD federating to each). Users have one identity but log into the appropriate org.
- Reporting strategy — cross-org reporting is the hardest part. Options:
- Replicate read-only into a data warehouse (Snowflake/BigQuery) and report from there.
- CRM Analytics can pull from multiple orgs into a unified analytics layer.
- Data Cloud (if licensed) can ingest from multiple orgs and provide a unified view.
- Governance — change control across orgs. Versioning of shared metadata. Cross-org release calendar.
- Cost & licensing — every spoke org needs its own licensing. Plan for that.
Common mistake: starting multi-org because it feels like it solves a problem, when actually a single org with proper sharing and Apps would have done. Multi-org is a one-way street that makes everything more expensive forever. The senior answer is: be very sure before you commit.