Multi-org enterprise: 5+ Salesforce orgs across business units / regions / acquisitions.
Drivers:
- M&A — newly acquired companies on their own Salesforce.
- Regulatory — financial services divisions can't share data.
- Data residency — EU data in EU, US data in US.
- Independent business units — autonomous IT.
Architectural approach:
1. Define the org topology.
Common patterns:
- Hub-and-spoke — central org holds master data; spokes have BU-specific data.
- Federation — peer orgs sync via integration; no central authority.
- Domain-based — orgs split by data domain (CRM, Service, Marketing).
2. Identity strategy.
- SSO via single IdP (Okta, Azure AD, Ping) — users log in once; access multiple orgs based on permissions.
- Just-in-time provisioning — create user in target org on first SSO login.
- Identity Connect for AD synchronisation.
3. Cross-org data architecture.
- Master Data Management (MDM) — single canonical record per customer / product / employee.
- Salesforce can be MDM, or external MDM tool (Informatica, Reltio, Stibo).
- Replication — Customer record in hub propagates to all spokes.
- Federation — query across orgs in real time (Salesforce Connect / external objects).
4. Integration architecture.
- Mulesoft / iPaaS as the integration backbone.
- Pub/Sub API + CDC for real-time event flow.
- Bulk API for batch sync.
- Salesforce-to-Salesforce for low-volume cross-org.
5. Reporting and analytics.
- Cross-org reports require external warehousing (Snowflake / BigQuery).
- CRM Analytics can pull from multiple orgs.
- Data Cloud for unified customer view across orgs.
6. Governance.
- Center of Excellence spans all orgs.
- Standards documentation — every org follows them.
- Architecture Review Board with cross-org members.
- Release coordination — when does each org get the changes?
7. Operations.
- Per-org admin — local accountability.
- Central platform team — strategic direction.
- Shared tooling — DevOps Center, Mulesoft, monitoring.
- Escalation paths — who fixes what.
8. Talent and capacity.
- Architects allocated by domain or region.
- Shared resources — security architect, integration architect.
- Per-org admins / devs for daily work.
9. Cost optimisation.
- License consolidation — bulk negotiate across orgs.
- Sandbox sharing where possible.
- Standard tools to reduce per-org licensing.
Common pitfalls:
- Org count grows accidentally — every M&A adds one; never consolidate. Plan consolidation explicitly.
- Inconsistent governance — each org drifts; org-specific quirks accumulate.
- Integration complexity — N orgs = N×N integration possibilities.
- Reporting blind spots — cross-org views absent; leadership flies blind.
Senior architect insight: multi-org is strategic infrastructure. Treat it with rigor — central authority, governance, standards, integration backbone. Without these, you have N separate Salesforce orgs that happen to have the same vendor.
Plan for evolution. Multi-org topology may need to change as business changes (e.g., consolidate post-acquisition, split for regulatory reasons).
The most senior framing: multi-org is a one-way street into; consolidating back is rare and expensive. Decide carefully.