Every few months, I encounter an organization that has built itself into a multi-org architecture not because it was the right choice, but because no one ever stopped to ask whether it was. The decision to split your Salesforce footprint across multiple orgs is one of the most expensive and irreversible architectural choices you can make. It deserves a rigorous decision framework, not a default.
I’ve worked on both sides of this — orgs that desperately needed to split and orgs that should never have split in the first place. Here is everything I know about making this decision well.
The Core Trade-Off
Before going any further: single org is the default choice. The burden of proof lies with multi-org. If you cannot articulate a clear, non-negotiable business or legal requirement that a single org cannot satisfy, you should stay on a single org.
When Multi-Org Is Actually Justified
Regulatory and Data Sovereignty Requirements
If your organization operates in jurisdictions with conflicting data residency laws — for example, EU GDPR requirements that certain data cannot leave European servers, combined with US operations where that same data type is needed — separate orgs with region-specific Salesforce instances may be the only compliant path.
This is a legitimate, non-negotiable reason.
Post-Acquisition Integration
A company you acquired has its own Salesforce org with years of customization, a live user base, and its own IT team. The cost and risk of merging into your org in the short term exceeds the cost of operating both. This is a common and valid justification — but with a clear expectation that consolidation is the eventual goal.
A multi-org architecture in this context should be treated as a transitional state, not a permanent design. Without a deadline, multi-org becomes permanent by inertia.
Business Units That Must Operate Independently
When two business units have genuinely separate customer bases, separate product lines, no cross-sell motion, and separate P&Ls where the CEO of one unit would not accept another unit’s admin having visibility into their data — separate orgs can be appropriate.
Note the emphasis on “genuinely.” Many organizations use this rationale when what they actually need is robust permission sets and record-level sharing rules.
Independent Release Cadences
Some organizations need one business unit to move fast with frequent deployments while another is in a tightly controlled regulated environment where changes require lengthy approval cycles. A single org forces both onto the same release cadence. This is a weaker justification than the ones above but is a real operational concern.
Multi-Org Topology Patterns
Hub and Spoke Pattern Details
A single “master” org holds the system of record for shared data (Accounts, Products, Pricing). Regional or business unit orgs connect to the hub to read shared data and write their own operational data back. The hub does not contain operational UI — it is purely a data platform.
This pattern works well for global manufacturers with regional sales orgs that need shared product catalogs but independent opportunity management.
Peer-to-Peer Pattern Details
Two or more orgs synchronize data in both directions through a defined set of shared objects. This is the most complex topology to maintain because every sync relationship is bidirectional and every schema change to a shared object must be coordinated across all peer orgs simultaneously.
I rarely recommend this pattern for new architectures. It is usually inherited from acquisitions.
Integration via ESB/iPaaS Pattern Details
All orgs connect to a central integration layer (MuleSoft, Boomi, or similar) rather than directly to each other. The integration layer owns the canonical data model and transformation logic. This is the most enterprise-grade pattern and the most expensive, but it is the cleanest separation of concerns.
Salesforce Connect: Cross-Org Read Access
Salesforce Connect allows you to surface data from an external system — including another Salesforce org — as External Objects in your org. Records appear in list views, related lists, and reports as if they were local records, but they are fetched on demand from the source system.
// External Objects appear in SOQL like local objects
List<ExternalObject__x> extRecords = [
SELECT ExternalId, Name, Status__c
FROM PartnerAccount__x
WHERE Status__c = 'Active'
];When It Works Well
- Read-heavy use cases where you need to display data from Org B in Org A’s UI
- Data that changes infrequently (product catalog, account master data)
- Scenarios where a field-by-field display in related lists is sufficient
Limitations
- Every record access counts against your OData call limits
- You cannot write back to the external system via External Objects alone — you need a REST callout
- SOQL on External Objects does not support all operators and cannot be used in some reporting contexts
- Reports that join local and external objects have performance constraints
If you are doing high-volume operations against the external data, replicating it into local custom objects via batch sync is more performant.
Data Synchronization Patterns
Change Data Capture (CDC)
Salesforce CDC publishes change events to a streaming channel whenever a record is created, updated, deleted, or undeleted. A subscribing system in another org can listen to these events and replicate the changes.
// CDC events are consumed via Apex triggers on the Change Event object
trigger AccountCDCTrigger on AccountChangeEvent (after insert) {
for (AccountChangeEvent event : Trigger.new) {
// Process change events — inspect header for change type
EventBus.ChangeEventHeader header = event.ChangeEventHeader;
if (header.getChangeType() == 'UPDATE') {
// Handle updated accounts
}
}
}CDC is the most real-time synchronization mechanism available on the platform. Latency is typically under 5 seconds. The limitation is that CDC events are only available for 3 days, so your consumer must stay current or you need a full-resync mechanism.
Platform Events for Custom Sync
For custom synchronization logic — for example, syncing only specific fields or applying transformation logic — Platform Events give you more control than CDC:
// Publishing from source org
AccountSyncEvent__e evt = new AccountSyncEvent__e(
AccountId__c = acc.Id,
Name__c = acc.Name,
BillingCountry__c = acc.BillingCountry,
SyncTimestamp__c = System.now()
);
EventBus.publish(evt);The consuming org subscribes via a trigger, a Flow, or an external process that calls the target org’s REST API.
Batch Replication
Batch Replication Steps (High-Volume / Historical)
For high-volume historical data or initial data loads, a nightly batch job using the Bulk API is more reliable than streaming:
- Source org: Bulk API query all modified records in the last 24 hours
- Transform: map source object fields to target object fields
- Target org: Bulk API upsert with ExternalId matching
This pattern sacrifices real-time for reliability and is appropriate for data that doesn’t need to be synchronized in minutes.
MuleSoft and Heroku Connect
MuleSoft
MuleSoft’s Anypoint Platform is the enterprise choice when your multi-org integration sits within a larger integration landscape that includes non-Salesforce systems. MuleSoft owns the canonical data model, applies transformation, and routes events between orgs without either org being directly aware of the other.
The cost is significant — MuleSoft licenses are not cheap. But if your organization already has a MuleSoft platform, adding Salesforce org integration to it is often the right call.
Heroku Connect
Heroku Connect provides bidirectional sync between a Heroku Postgres database and a Salesforce org. It is not a multi-Salesforce-org tool. Where it fits in a multi-org architecture is as a data warehouse layer: sync all orgs into Heroku Postgres, then build reporting against the combined dataset.
Problem: Your company acquired a smaller firm 18 months ago. Both orgs are still running independently, integration is a tangle of point-to-point REST callouts, and no one can produce a unified pipeline report. The original consolidation timeline has slipped twice.
Solution: Set a hard deadline for consolidation and treat the current state as technical debt, not architecture. In the meantime, implement Change Data Capture on shared objects (Account, Contact) to drive near-real-time sync, build a combined reporting layer in Tableau CRM fed from both orgs, and assign one architect who owns the consolidation roadmap with executive sponsorship. Multi-org without an owner and a deadline becomes permanent by default.
Before concluding that cross-org reporting requires an expensive middleware layer, check whether Salesforce Connect’s OData adapter (available at no extra cost with certain editions) can surface the secondary org’s key reporting objects as External Objects in your primary org. For read-only reporting on a handful of objects with moderate record volumes, this eliminates the need for replication entirely.
The Decision Framework
Before approving a multi-org architecture, answer these questions honestly:
1. Can this be solved with Communities/Experience Cloud? — If the goal is to give a partner or external user access to a subset of your data, Experience Cloud is almost always cheaper and simpler than a separate org.
2. Can this be solved with permission sets and sharing rules? — Data visibility concerns within a single org are usually solvable through record-level security without physical separation.
3. What is your reporting strategy? — If you need combined reporting across the proposed orgs, map out exactly how you will achieve it. “We’ll figure it out” is not an answer.
4. Do you have the team to run two orgs? — Every org needs a release pipeline, admin coverage, monitoring, and backup strategy. Do you have that capacity twice over?
5. Is this acquisition temporary? — If you are integrating an acquired company’s org, define the consolidation timeline upfront. Without a deadline, multi-org becomes permanent by inertia.
If you cannot answer all five questions satisfactorily, go back to single org and address the underlying requirements differently.
What architectural decisions around org strategy have you found most difficult to get right in your projects, and what did you learn from getting them wrong?
How did this article make you feel?
Comments
Salesforce Tip