The choice between one Salesforce org and several is usually argued as a technical design question and settled by governance. It tends to surface during an acquisition, a compliance audit or when a business unit asks for its own environment, rarely during a deliberate review. The questions that decide it belong to the operating model: who owns the shared data definitions, who can release when, and which org is the system of record for which object. Answer those first and the topology follows.
What a single org assumes
A single org assumes the organisation can agree on one definition of Account, one set of Opportunity stages and one set of lifecycle rules, and that some governance body can refuse a local variant. It also assumes coordinated releases: every team deploying into the org shares sandboxes, deployment windows and regression tests.
When the business is uniform, that trade is worth it: one data model, one release process, reporting without integration. When it is not, the cost shows up in the permission model, in page layouts that multiply and in automation that branches to handle what are really different processes. A simple test is to list the conditional branches in the Account hierarchy, the sharing model and the automations that exist only because business units differ. When that list keeps growing, the org is running several systems in one database.
Sanofi (a Cognizant client, 2021-2022) is the consolidation case: six systems migrated into a single Salesforce org. A consolidation of that kind brings the definitions question forward. Each source carries its own version of a customer or a product, and the single org accepts one. That negotiation comes before the record migration, which is the last step. The note on Salesforce data migration covers what has to be proven before cutover.
A single org also needs an owner. Without named ownership of custom objects, Flows and Apex classes, dependencies turn opaque and teams stop touching components they cannot test without regressions. The org stays technically one and splits in practice. The note on the Salesforce Center of Excellence describes the layer that holds that ownership.
When separate orgs are justified
Separate orgs are justified when isolation is a hard requirement. A legal entity under a different regulatory regime may need a separation of data and access that it can show an auditor more easily than a sharing model inside a shared org. A recently acquired company may need its own org during a transition, because a forced migration in its first months is rarely realistic. Business units with incompatible release cycles may need separate orgs so that the fastest team is not held to the slowest team’s calendar.
The pattern to avoid is multi-org as a governance shortcut: several orgs because nobody could agree on a shared data model. That defers the disagreement and adds a permanent integration layer, separate release processes, separate permission audits and a second admin team. A “temporary” org created for an acquisition or a pilot also becomes permanent unless someone sets an exit decision with a date.
The data contract between orgs
Shared definitions do not disappear with a second org. Lacoste’s multi-market Customer 360 programme (2023) covered six business units. Whether units like these share one org or feed several, each of them needs the same answer on who defines a customer and who may change that definition. In a single org the answer lives in governance. Across several orgs it has to be written down as a data contract.
A multi-org setup rarely fails because an API is missing. It fails when two teams change the same value, each with its own definition of it, and no rule decides between them. The contract is kept per business object, not per interface. For each shared attribute it names the system of record, the systems that may read it, the systems that may propose a correction without writing it directly, and the rule applied when a source value is missing, invalid or in conflict.
Take a phone number. If the service org may correct it after a call with the customer, the sales org must not push the old value back at the next sync. Either the correction goes to the system of record before it spreads, or the contract sets a documented priority rule with an audit trail. Accepting a silent overwrite because the integration technically succeeded is the worst option.
The contract also says who may change the shared definitions. Adding an optional field can usually ship without breaking anyone. Making a field required, changing an identifier or replacing a picklist triggers a compatibility review with every consuming org, a new version and a retirement date for what is replaced. Each interface has a named owner on the producing side, who fixes the source, and on the consuming side, who confirms the change is absorbed.
A central data layer does not remove that work. Salesforce made Data Cloud One generally available in October 2024 to share Data Cloud data with several orgs. That is a sharing capability. It does not make the central layer the operational system of record, and it does not decide who owns an email address.
Changing course
Reversing the choice is expensive in both directions, and the technical work is the manageable part. Agreeing on what goes where, who owns the master data and how shared processes are divided is where these programmes stall.
For a split, start with data, not configuration. Map every object and every integration dependency, name the owner of each shared object after the split, and build the integration alongside the existing org rather than after it. Run both in parallel for a defined period to check data integrity before cutting over.
For a consolidation, the data model negotiation comes first. Merging two orgs without an agreed Account model produces an org worse than either original.
For a temporary org, set the exit criteria when it is created: the date of the decision to merge or keep it, and who takes that decision.
What to check
- Each shared object has a named system of record and a named owner of its definition.
- The reason for every separate org is written down: regulatory isolation, an acquisition in transition or release independence.
- Any temporary org has an exit decision with a date and a decision-maker.
- Changes to shared definitions go through a compatibility review with the consuming orgs.
- In a single org, one body can refuse a local variant of Account or of the Opportunity stages.