Data Cloud One: how to give five Salesforce orgs one Data 360 without five bills

Almost no enterprise runs a single Salesforce org. There’s a sales org and a service org that never got merged. There’s the org that came in with an acquisition and still runs its own automation. There’s a regional instance that exists because a data-residency lawyer said so. Each of these has customers, and each of them, the moment someone says the word “AI,” wants a unified, deduplicated, grounded view of those customers. The naive answer — stand up a full Data 360 in every org — is how you end up paying for the same ingestion five times, resolving the same identities five different ways, and explaining to finance why the “single source of truth” has five sources.

Data Cloud One is Salesforce’s answer to exactly this shape of problem, and it’s one of the least-discussed features in the whole Data 360 surface because it’s boring in the best way: it’s plumbing. It lets you designate one org as the home org that does all the heavy lifting — ingestion, harmonization, identity resolution — and connect your other orgs to it as companion orgs that read and act on that unified data without owning a copy of the machinery. This post is how it actually works, what a companion org can and can’t do, and the licensing and lifecycle edges that decide whether it saves you money or quietly creates a new mess.

First, a naming note, because the rebrand matters here. Salesforce renamed Data Cloud to Data 360 at Dreamforce in October 2025, folding it under the Agentforce 360 umbrella. The license, data model, and tooling didn’t change — the name did. The multi-org feature, confusingly, kept its original branding: it’s still called Data Cloud One, and Salesforce’s own docs now talk about a “Data 360 home org.” I’ll use Data 360 for the platform and Data Cloud One for the multi-org capability, which is how the current documentation splits it.

The problem Data Cloud One actually solves

The default multi-org pattern for Data Cloud, before this existed, was grim. If org A and org B both wanted unified profiles, you provisioned Data Cloud in both, ingested overlapping data into both, and either accepted two divergent versions of the customer or built a fragile cross-org sync to reconcile them. You paid the ingestion and processing meter twice for data that was substantially the same. And your identity resolution rules — the ones that decide whether [email protected] and [email protected] are one person — lived in two places, drifting apart the moment someone tuned one and forgot the other.

Data Cloud One collapses that. There is one place where data lands, one place where it’s unified, one set of match rules, one governed profile. Everything else connects to it.

The point of Data Cloud One isn’t to give every org its own data platform. It’s the opposite — to make sure every org is reading from the same platform, so “the customer” means one thing across your entire estate instead of one thing per org.

It’s worth being clear about what this is not. It is not zero copy, which federates query access to an external warehouse like Snowflake without moving the data. And it is not data spaces, which partition a single Data 360 instance so that, say, your EMEA brand and your US brand don’t unify into each other. Data Cloud One operates one level up from data spaces: it’s about connecting separate Salesforce orgs to one Data 360, where data spaces are about carving up one Data 360 internally. Teams conflate the two constantly, and the distinction is load-bearing — you can absolutely use both together, with companion orgs reading from specific data spaces in the home org.

The architecture: one home org does the work, companions consume it

The mental model is a hub and spokes. The home org holds the Data 360 instance and does the foundational work: ingesting data from every connected source, harmonizing it to the data model, and running identity resolution to produce unified profiles. Everything expensive and stateful lives here.

A companion org is a regular Salesforce org that connects to the home org through a companion connection and gets a Data Cloud One app. Through that app, users in the companion org get an accessible view of the home org’s unified data and — this is the part that surprises people — the ability to act on it locally. A companion org isn’t a read-only dashboard. From the current documentation, companion org users can:

• See unified customer profiles resolved in the home org.
• Build and run segments using the home org’s attribute library, refined with filters and enriched with calculated insights.
• Use calculated insights and CRM enrichments to bring unified metrics onto their own CRM records.
• Fire Data Cloud-triggered flows on home-org data changes.
• Ground AI agents and use Agentforce Data Library on the unified data.
• Reach multi-cloud features like Prospecting Center.

What the companion org does not do is the foundational layer. It doesn’t run its own ingestion, harmonization, or identity resolution — it leverages the home org for all of that. That’s the whole economic argument: you pay for the machinery once, in the home org, and the companion orgs consume the output. Think of the home org as the factory and the companion orgs as storefronts that sell what the factory makes without each building their own factory.

Practically, that split dictates where you put the home org. It should be the org that owns the richest data and the identity strategy — often a central “data” org or the primary CRM. The acquisition’s org, the regional instance, the standalone service org: those are your companions.

Setting it up: SKUs, connections, and the order of operations

Setup is genuinely point-and-click — Salesforce’s own framing is “connect multiple orgs with clicks, not code” — but there’s a SKU dance you have to get right, and the sequence matters more than the clicks.

1. Designate the home org. This is the org with the Data 360 instance that does ingestion and unification. Get the data foundation right here first; a companion connection inherits the home org’s identity resolution and data model, warts and all.
2. Add the companion SKU to each companion org. Each org you want to connect needs a Data Cloud Companion entitlement — you add the free Data Cloud One Companion Org SKU to that org so it’s eligible to connect.
3. Create the companion connection from the home org to each companion org, and provision the Data Cloud One app in the companion.
4. Grant access in the companion org so the right users and profiles can see the unified data and build on it.

On cost: a Data 360 home org can make companion connections to three eligible CRM orgs for free. If you need to connect more than three, you buy Data Cloud One Additional Connection licenses and add them to the home org. So the first three spokes are included; the fourth onward is a line item. For most mid-size estates — a sales org, a service org, and one acquisition — you’re inside the free tier, which is a genuinely rare thing to be able to say about a Salesforce data feature. Verify the current entitlement details against Salesforce Help before you commit an architecture to it, because SKU packaging is exactly the kind of thing that moves between releases.

The SDLC trap nobody warns you about

Here’s the edge that bites teams in production, and it’s not in the marketing: sandboxes and the order you connect things in.

A companion connection carries metadata implications. If you connect your production org as a companion first and then try to sort out sandboxes afterward, you can end up doing metadata cleanup you didn’t budget for. The practitioner guidance that’s emerged is to create your sandbox orgs and get your companion topology straight before you wire production in as a companion, so you’re not untangling connections in a live environment. This is the multi-org version of a lesson we’ve argued generally in our sandbox strategy writeup: the environments and the promotion path are part of the design, not an afterthought you bolt on once production is live.

Two more operational notes worth surfacing before a rollout:

• The home org is now a shared dependency. When five orgs read from one Data 360, an identity-resolution change or a data-model tweak in the home org ripples to all of them. That’s the point — one source of truth — but it also means home-org changes need change control proportionate to their blast radius. A match-rule edit is no longer a one-org decision.
• Data residency doesn’t disappear. If one of your orgs exists specifically because data has to stay in a region, connecting it as a companion to a home org in another region is a compliance question, not a checkbox. Companion orgs read the home org’s data; make sure that read is allowed to cross the boundary before you draw the arrow.

When Data Cloud One is the wrong tool

It usually isn’t — for genuine multi-org estates that want unified data, it’s close to a default. But there are shapes where it’s a poor fit, and naming them keeps you honest.

If your orgs serve genuinely separate businesses with no shared customers and no reason to unify, you don’t need a shared home org at all — you might just want independent Data 360 instances, or Data 360 in only the org that needs it. If the thing you actually want is to keep data out of Salesforce entirely and query it in place, that’s zero copy, not Data Cloud One. And if you’re one org trying to keep two brands from cross-contaminating, that’s data spaces, a within-org partition, not a cross-org connection.

The deeper question underneath all of this is whether you need the full Data 360 platform at all for what you’re doing — a question we mapped in does Agentforce need Data Cloud. Data Cloud One doesn’t change that calculus; it changes the topology once you’ve decided you’re in. If you’ve already sized your consumption, our Data 360 pricing guide explains how the credit meter behaves — and the good news is that consolidating ingestion into one home org is one of the cleaner ways to avoid paying for the same data twice.

What to actually do

Data Cloud One is the feature you reach for the moment your Salesforce estate stops being one org and your data strategy has to survive that. The pattern is simple to state and easy to get subtly wrong: put the identity strategy and the ingestion in one home org, connect everything else as a companion, and resist the temptation to let any companion start doing its own unification.

Concretely: pick the home org by where the richest data and the identity rules already live, not by org size or politics. Get the home org’s identity resolution and data model solid before you connect a single companion, because companions inherit both. Use the three free connections and only buy Additional Connection licenses when you genuinely outgrow them. Sequence your sandboxes before you wire production in. And treat home-org changes with the change control their new blast radius deserves. Do that, and “the customer” means one thing across your whole estate — which is the entire reason to unify data in the first place. Skip it, and you’ve just built five expensive versions of the same truth.

If you’re staring at a multi-org estate and trying to work out which org should be the home, how many companion connections you’ll actually need, and whether your regulated data can cross an org boundary, talk to us — designing a Data 360 topology that unifies the estate without paying for it five times is exactly the work we do, and it’s the foundation everything grounded in your data stands on.

Understanding the basics

What is Data Cloud One?

Data Cloud One is the multi-org capability of Salesforce Data 360 (formerly Data Cloud). It lets you run a single Data 360 instance in one home org — which handles ingestion, harmonization, and identity resolution — and connect your other Salesforce orgs to it as companion orgs that read and act on the unified data through a Data Cloud One app, without each running its own copy of the platform. It’s configured point-and-click, with no custom code required.

What can a companion org do versus the home org?

The home org does all the foundational work: ingesting data, harmonizing it to the data model, and running identity resolution to produce unified profiles. A companion org consumes that output — its users can view unified profiles, build segments from the home org’s attributes, use calculated insights and CRM enrichments, fire Data Cloud-triggered flows, and ground AI agents and the Agentforce Data Library on the unified data. What a companion org does not do is its own ingestion or unification; it leverages the central home org for all of that.

How many companion connections do you get, and what do they cost?

A Data 360 home org includes three free companion connections to eligible CRM orgs. To connect more than three, you buy Data Cloud One Additional Connection licenses and add them to the home org. Each companion org also needs the free Data Cloud One Companion Org SKU added to it before it can connect. Confirm the current entitlement and packaging against Salesforce Help, since SKU details can change between releases.

Is Data Cloud One the same as data spaces or zero copy?

No. Data spaces partition a single Data 360 instance so that different brands or regions don’t unify into each other — that’s within one org. Zero copy federates query access to external data (such as Snowflake) without moving it. Data Cloud One connects separate Salesforce orgs to one shared Data 360 home org. They solve different problems and are frequently used together — for example, a companion org reading from a specific data space in the home org.

---

Working out the right home-org choice and companion topology for a multi-org Salesforce estate — and whether your regulated data can cross the boundary? Talk to us. Getting the Data 360 foundation right so every org reads one version of the customer is exactly the work we do.