Data 360
Data 360 in a sandbox: what you can test, and what stays empty
Data 360 is available in every sandbox now, but the sandbox is metadata-only: your config copies across and your data doesn't, even in Full Copy. Here's what that lets you validate before go-live, what you can't preview without ingesting your own sample, and the provisioning and refresh gotchas that catch teams mid-project.
A team is a week from a Data 360 go-live. They want to prove the identity resolution before it touches production, so they refresh a Full Copy sandbox, open Data 360, and find it empty. No profiles. No segment counts. The config is all there. The data is not.
That surprise is worth understanding before you plan a project around it, because it changes what a Data 360 sandbox is for. So the short of it: a Data 360 sandbox is metadata-only. It copies your configuration and none of your data, even in a Full Copy, and that single fact decides what you can validate before go-live and what you can’t.
Data 360 is the current name for what was Data Cloud until October 2025, and much of the tooling still says data-cloud and c360. The sandbox behavior below is the same either way, and it’s different enough from a CRM sandbox that assuming parity will cost you a sprint.
What “metadata-only” actually copies
Data 360 has been generally available across sandboxes since late 2024, in every type: Developer, Developer Pro, Partial Copy, and Full Copy. What “available” means here is narrower than people expect.
When you create or refresh the sandbox, Salesforce replicates the Data 360 metadata and configuration from production. Data streams, data lake objects, data model objects, mappings, identity resolution rulesets, calculated insight definitions, segments, activation definitions: the shapes all come across. The rows do not.
No ingested data is replicated, and this holds even in a Partial Copy or Full Copy sandbox, where a CRM admin is used to getting sample or complete data.
A Full Copy sandbox copies your CRM data. It does not copy your Data 360 data. The Data 360 side is metadata-only regardless of sandbox tier, and that catches the teams that pay for Full Copy precisely to test with real volume.
Two more things stay behind. Authentication information isn’t replicated, and neither are the live connections, so every external connection has to be reconfigured in the sandbox before it does anything. A copied connector definition is a shell until you authenticate it against the sandbox.
What you can genuinely test
Empty of data does not mean empty of value. There’s a real amount you can validate in a Data 360 sandbox, as long as you bring the data yourself.
You can build and revise the model. Data streams, DLO-to-DMO mappings, transforms, calculated insight definitions, segment logic, and activation setup are all configurable and testable as configuration. If your work is “does this pipeline wire up correctly,” the sandbox answers it.
You can test ingestion. Point a data stream at a source and run it, and you can watch the ingestion path work end to end. You can also test federated, zero-copy access to an external lake or warehouse, since that reads data live from the source rather than depending on data copied into the sandbox.
The move that makes the rest possible is to ingest a small, representative dataset yourself. Load a controlled sample through a data stream, and now the empty sandbox has enough data to exercise the parts that need rows: run a ruleset against it, build a segment, see membership. You’re not previewing production’s outcomes, you’re validating that the logic behaves on data you understand, which is often the better test anyway.
What you can’t preview, and why it matters
The gap is the one the go-live team hit. Without production data in the sandbox, you cannot preview production’s identity resolution or segmentation outcomes.
You can’t see how many profiles your ruleset will consolidate, or whether a loose match rule over-merges two real customers, until there’s representative data to resolve. Given that one loose match rule can fuse two customers into one profile and every downstream activation inherits the error, the instinct to validate resolution before go-live is the right one.
The sandbox just won’t do it from copied production data. It does it from a sample you load, or not at all.
Segment counts are the same story. A segment definition is testable; the population it would produce against production volume is not, because the volume isn’t there. Plan your pre-go-live validation around a representative sample you control, and treat production membership numbers as something you confirm in production, carefully, not something the sandbox predicts.
Activations carry a specific catch. Activation targets copy from production into the sandbox, but you can’t actually activate through them until the underlying connector is enabled and authenticated in that sandbox. A copied activation target that looks ready will sit inert until you finish wiring its connection.
The deployment direction has its own rules
Moving the other way, from sandbox to production, is a separate discipline with its own sharp edges, and it’s worth naming because sandbox testing and deployment get planned together.
Most Data 360 configuration has no Change Set path, so teams reach for the Salesforce CLI, the Metadata API, DevOps Center, or a DevOps Data Kit that collects and sequences the config. The sequencing is the hard part, since a segment depends on the DMO that depends on the stream.
We wrote the Data Kits deployment guide for exactly that problem, and it’s the companion to this post: test in the sandbox, deploy with a kit.
One asymmetry to know now, while you’re deciding what to build where. Certain features can’t be deployed back to production from a sandbox, among them native activations, external ecosystem targets, and Data Clean Room. If your architecture leans on those, plan to build them directly in production with a change-controlled process, not to promote them from a sandbox.
The provisioning and refresh gotchas
A few operational realities catch teams mid-project, and they’re cheaper to know than to discover.
Provisioning isn’t automatic on every sandbox. Data 360 in a sandbox depends on the appropriate Data Cloud sandbox entitlement, and older sandboxes created before Data 360 was enabled for them need a refresh before Data 360 provisions at all. If Data 360 isn’t showing up in a sandbox you expected it in, a refresh is the usual first move, entitlement permitting.
Refresh itself is not free of risk. Salesforce has documented a known issue where refreshing a sandbox can disrupt the Data 360 setup in it, which matters because refresh is also how you pull the latest production metadata. Treat a refresh as an event to validate after, not a no-op, and rebuild or reconfigure what the refresh disturbed before you trust the environment again.
Connections need re-authentication after every refresh, following from the earlier point that auth doesn’t replicate. Bake that into the runbook. A refreshed sandbox with stale credentials is a sandbox where half your streams silently do nothing.
What to do
Decide what the sandbox is for before you provision it. If the goal is to validate that your model, mappings, and pipeline logic are correct, a Data 360 sandbox does that well, and a Developer or Partial Copy tier is usually enough. Don’t pay for Full Copy expecting it to fill Data 360 with production data, because it won’t.
If the goal is to validate identity resolution and segmentation behavior, plan to ingest a small, representative, well-understood sample and test against that. It’s a more controlled test than production data would give you, and it’s the only kind the sandbox supports. Reserve the true volume-and-outcome check for a careful, monitored pass in production.
Then wire the two directions together. Test configuration and logic in the sandbox, load a sample for the parts that need rows, and promote with a data kit and a deliberate sequence rather than hoping a Change Set carries it.
Reconfigure connections after every refresh, and keep the features that can’t leave production out of your promotion plan. Do that, and the empty sandbox stops being a surprise and becomes a stage you know the limits of.
For the CRM environment topology around all of this, our sandbox strategy guide covers right-sizing tiers and refresh discipline for the org as a whole, and Data 360’s metadata-only behavior sits inside that larger plan.
Understanding the basics
Does a Data 360 sandbox contain production data?
No. Data 360 sandboxes are metadata-only: they replicate your configuration, such as data streams, data model objects, mappings, rulesets, calculated insight definitions, segments, and activation setup, but no ingested data, and this holds even in a Partial Copy or Full Copy sandbox. Authentication and live connections aren’t replicated either. To test anything that needs rows, you ingest a small, representative dataset into the sandbox yourself.
Can I test identity resolution in a Data 360 sandbox?
Only against data you load, not against production. Because no production data is copied in, you can’t preview how a ruleset would consolidate your real profiles or whether a match rule over-merges customers, until there’s representative data in the sandbox to resolve. The reliable pattern is to ingest a controlled sample through a data stream, run the ruleset against that, and confirm the logic behaves, then validate true production outcomes carefully in production.
Which sandbox types support Data 360?
All of them: Developer, Developer Pro, Partial Copy, and Full Copy, generally available since late 2024. The tier changes how much CRM data comes across, not the Data 360 behavior, which is metadata-only in every tier. Provisioning depends on the appropriate Data Cloud sandbox entitlement, and older sandboxes may need a refresh before Data 360 becomes available in them.
How do I move Data 360 config from a sandbox to production?
Not with Change Sets, which don’t carry most Data 360 configuration. Teams use the Salesforce CLI, the Metadata API, DevOps Center, or a DevOps Data Kit that collects and sequences the configuration, respecting the dependency order where a segment relies on a DMO that relies on a stream. A few features, including native activations, external ecosystem targets, and Data Clean Room, can’t be deployed back to production and need to be built there directly.
Planning a Data 360 go-live and trying to validate the pipeline and the identity resolution before it touches production, without mistaking an empty sandbox for a broken one? Talk to us, getting the environment strategy and the deployment sequence right is exactly the work we do. Our integration and Data Cloud practice does this kind of build.
