Data 360
The Data 360 data space tax: why every new brand rebuilds your config
Stand up a second data space for a new brand or region and you discover the hard truth: none of your DMO mappings, segments, or process definitions come with you. You rebuild them by hand, per space, forever. Data kits are the fix, but the one-click cross-space deployment is sandbox-only. Here's the replication path, what it moves, and what it leaves behind.
You spent weeks getting the first data space right. The streams land clean, the DMO mappings are correct, the calculated insights compute what finance asked for, the segments are tuned.
Then the business adds a second brand that can’t share a customer graph with the first. So you create a second data space, and none of it came with you. Empty. You’re rebuilding the same mappings, the same segment logic, the same transforms, by hand. And you’ll do it again for the third brand, and the fourth region.
That’s the data space tax, and it’s the cost nobody quotes you when you decide to partition. A data space is a hard boundary by design, which is the whole reason to use one. But the same wall that keeps two brands’ profiles from unifying stops your configuration from crossing between them.
The fix exists. It’s data kits. But the cleanest form of it, one-click replication from your default space into the others, only runs in a sandbox. Knowing that before you plan a multi-brand rollout is the difference between a repeatable promotion path and a quarter of copy-paste.
Why a data space walls off your config, along with your data
It helps to be precise about what a data space is, because the tax follows directly from it. A data space is a logical partition for profile unification, insights, and access. Segregate your data by brand, region, or business unit into separate spaces, and profiles that unify inside one don’t cross into another. Grant a user access to a space and they see only that space’s data.
I’ve written the full one-versus-many data space decision elsewhere. The rule of thumb: create a separate space only for a boundary that must not be crossed, because the boundary is expensive to maintain and hard to undo.
The expense is the config. When you build a DMO mapping, a segment definition, or a process definition in one data space, that work stays in that space. It doesn’t help you in the next one.
So every new space repeats the setup. Worse, every later change has to be re-applied in each space by hand, which turns a one-line edit into a chore that scales with the number of brands you run. The partition that protects your data isolates your metadata right along with it.
This isn’t a bug you can configure away. It’s the direct consequence of the isolation you asked for. The question is how to move configuration across a boundary built to stop things from moving, and the answer is the primitive that moves Data 360 config anywhere: the data kit.
Data kits are the suitcase, and the config lives in a separate plane
The reason ordinary Salesforce deployment tools don’t help here is worth stating. A Data Model Object, a data stream, a calculated insight, a data graph: these are Data 360 metadata. They live in a plane deliberately separate from your core Salesforce objects, fields, and Flows.
That separation is what lets Data 360 scale independently on an open format underneath. It’s also why a Change Set never saw your Data 360 config, and why many of these components can’t be deployed on their own at all. A DMO or a calculated insight isn’t independently deployable the way a custom object is. It has to travel inside a container.
A data kit is that container: a metadata suitcase that bundles related Data 360 components so they deploy together, in dependency order, as a unit. It’s the application-lifecycle primitive for Data 360.
If you’ve read our take on DevOps Center versus Change Sets, this is the Data 360 chapter of that story, and the full mechanics of moving Data 360 config from sandbox to production sit alongside this post. Here the job is narrower: config that has to cross data spaces, not org boundaries.
The one-click path across spaces is a sandbox feature
This is the part to internalize before you plan a rollout, because it shapes the whole sequence.
Data 360 offers a local data kit deployment method that packages your metadata and process definitions from the default data space and pushes them into the other data spaces in the same org, in essentially a single action. That’s the tool built for exactly this tax. The catch: it runs in sandbox environments only. It’s not a production feature.
So the fast, one-click cross-space replication you want is real, and it lives in your sandbox. That’s less limiting than it sounds if you sequence around it.
Build and validate the mappings, segments, and transforms once in the default data space of a sandbox. Use local deployment to fan them out to the other spaces in that same sandbox, and confirm they behave.
Then promote the whole thing to production through the supported cross-environment path: a DevOps data kit deployed with the Salesforce CLI, the tool meant for moving Data 360 metadata from a sandbox to a production org you own.
Do the fanning-out in the sandbox where it’s one click, and promote the result to production as a unit. Don’t try to hand-replicate across production spaces after the fact.
One honest caveat. The exact steps for replicating config across data spaces in production are thinner in the documentation than the sandbox path, and the tooling is moving quickly. Confirm the current production sequence against Salesforce’s own docs, and ideally a scratch run in a sandbox, before you commit a multi-brand plan to a date.
What the suitcase carries, and what it leaves at the gate
A data kit doesn’t carry everything, and the gaps ruin a deployment plan if you learn them mid-rollout.
The components that travel are the schema-and-logic layer: DMOs and their mappings, data streams, calculated insights, batch data transforms, segments, and the definitions that make a space functional. That’s most of what the tax is about, so the kit covers the bulk of the pain.
The component that doesn’t travel is the activation target. Neither the DevOps path nor the packaging path carries activations, so the last mile that pushes a segment to an external destination stays a manual, per-space setup. Your kit moves the segment and the model it stands on, but someone still wires the activation target by hand in each space.
Plan for that explicitly. A segment that deployed cleanly but activates nowhere looks like a broken deployment when it’s really an unwired last mile.
A second thing to hold in mind is cost. Replication multiplies more than config. It multiplies consumption too, because each space you stand up runs its own identity resolution, its own insights, and its own streams, and each draws credits.
Fanning a chatty calculated insight across four brands is the same insight billed four times. Before you replicate, make sure the workload you’re copying is one you’d want running in every space, which is the discipline the credit-optimization playbook exists to enforce.
The tax you can automate away is the setup labor. The tax you can’t is the consumption, and that one scales with every space whether you replicate by hand or by kit.
Decide the partition before you pay the tax
The cheapest way to pay the data space tax is to owe less of it. Be ruthless about how many spaces you actually need.
A data space is the right tool for a boundary that must not be crossed: distinct legal entities or brands that can’t share a customer graph, or data-residency regimes that can’t commingle. It’s the wrong tool for “different teams should see different things,” where the permission-set and feature-access model restricts visibility without splitting the unified profile, and without duplicating a shred of config.
So here’s the sequence I’d run. Decide the boundaries first, and create only the spaces a real boundary demands. Build the config once in the default space of a sandbox. Fan it out to the other spaces there with local deployment while it’s a single action. Promote the validated result to production as a DevOps data kit through the CLI. Then wire the per-space activation targets by hand, because nothing carries those.
Get that order right and the second brand costs you a promotion, not a rebuild. Get it wrong, by splitting into spaces you didn’t need or hand-building each one, and you pay the tax every release, forever.
Understanding the basics
What is the Data 360 “data space tax”?
It’s the informal name for the setup cost of every new data space. Because a data space is a hard partition, your DMO mappings, segments, transforms, and process definitions don’t carry over from one space to another. Each new brand or region rebuilds the same configuration, and every later change has to be re-applied per space. The tax is the repeated setup and maintenance labor that scales with the number of spaces you run.
Can I copy Data 360 configuration from one data space to another?
Yes, using data kits. There’s a local data kit deployment method that packages config from your default data space and deploys it to the other spaces in the same org in roughly one action, but it runs in sandbox environments only. For production you promote a validated data kit from sandbox to your production org with the Salesforce CLI. Verify the current production cross-space steps against Salesforce docs, since the tooling is evolving.
Do data kits move everything between data spaces?
No. Data kits carry the schema-and-logic layer: DMOs and mappings, data streams, calculated insights, batch transforms, and segments. They don’t carry activation targets, so the last-mile setup that pushes a segment to an external destination stays a manual, per-space task. Some Data 360 components also can’t be deployed on their own and must travel inside a kit, which is exactly why the container exists.
Should I create a separate data space for each team?
Usually not. Create a separate data space only for a boundary that must not be crossed, like distinct brands or legal entities that can’t share a customer graph, or data-residency rules that can’t commingle. For merely showing different teams different data, use permission sets and feature-level access, which restrict visibility without partitioning the unified profile or duplicating any configuration. Fewer spaces means less tax.
Planning a multi-brand or multi-region Data 360 rollout and trying to avoid rebuilding it space by space? Talk to us about your data foundation. Sequencing the partition, the promotion path, and the activation wiring correctly is what turns the second brand into a deployment instead of a project.
