Data Kits in Data 360: how to actually move Data Cloud config from sandbox to production

Every Data 360 project reaches the same cliff. You spent weeks in a sandbox getting it right — the data streams mapped, the Data Model Objects keyed correctly, a calculated insight computing lifetime value, a segment that finally resolves the way the business wanted. Then someone asks the reasonable question: how do we get this to production? And you discover that the muscle memory of the last fifteen years — a Change Set, a package.xml, a click in DevOps Center — doesn’t carry most of it. Data Cloud metadata doesn’t ride the rails core platform metadata rides. Rebuild it by hand in production and you’ve reintroduced every mapping error you spent the sandbox eliminating.

Data Kits are how Salesforce closed that gap, and they’re one of the most under-explained corners of Data 360. The confusion isn’t whether they work — it’s that “data kit” names two different things depending on whether you’re distributing config to strangers or promoting it across your own orgs, and picking the wrong one wastes a sprint. This post is the practitioner’s version: what a data kit actually packages, the two kinds and when each is right, the hard limitations that shape your plan, and the dependency and schema rules that produce the errors nobody warns you about.

Why Data Cloud needs its own packaging at all

Start with the reason the problem exists. A Data Model Object, a Data Lake Object, a data stream, a calculated insight, a data graph — these are Data 360 metadata, and they live in a plane that’s deliberately separate from your core Salesforce objects, fields, and Flows. That separation is why Data 360 can scale independently and speak an open format underneath, but it’s also why the ordinary deployment tools don’t see it.

A data kit is the container that fixes this. Think of it as a metadata suitcase for Data 360: it bundles related Data Cloud components so they deploy together, in the right order, as a unit — instead of as a pile of loose objects that fail because one references another that isn’t there yet. It’s the ALM (application lifecycle management) primitive for Data Cloud, and it’s the thing that lets Data 360 participate in the same source-driven delivery discipline you’d expect for everything else. If you’ve read our take on DevOps Center versus Change Sets, this is the Data 360 chapter of that story: the config finally has a supported way to move.

What a data kit can carry

The packageable components are the ones you’d hope for, but the list has real edges, so it’s worth being exact. A data kit can include:

• Data streams — including CRM Data Streams and Amazon S3 Data Streams.
• Data Lake Objects and Data Model Objects — the schema layer, with custom data models carried as-is.
• Calculated insights — the metrics computed over your unified model.
• Batch data transforms — the transform logic that shapes data between layers.
• Data graphs — the pre-joined, denormalized views that ground agents and power fast retrieval.

Many of these components can’t be deployed on their own — a Data Model Object or a calculated insight isn’t independently deployable the way a custom object is. They have to be packaged inside a data kit, which is precisely why the container exists. The kit is not an optional convenience; for most of the Data 360 schema layer, it’s the only supported path.

And here’s the first edge that catches teams mid-deployment: activation targets are not supported by data kits — neither the second-generation packaging kit nor the older first-generation path carries them. Activations are the last mile that pushes a segment to an external destination, and they stay a manual, per-org setup step. Plan for it: your kit moves the segment and the model it stands on, but someone still wires the activation target in each org by hand.

The two kinds of data kit, and why people conflate them

This is the distinction that decides your whole approach, and the shared name buries it.

A DevOps data kit is for migrating Data 360 metadata from a sandbox to a production org — promotion across environments you own. This is what the overwhelming majority of implementation teams actually need. You build in a sandbox, wrap the components in a DevOps data kit, and deploy it to production, typically through the Salesforce CLI (sf commands) or a Deploy Data Kit Components flow. It is explicitly not meant for packaging config to distribute to other people — it’s an internal promotion tool.

A packaging data kit is for distribution: you embed the data kit inside a second-generation managed package (2GP) and ship it to orgs you don’t control — the classic ISV or template scenario, where the kit unpacks after the managed package installs. This is the right tool when you’re an AppExchange partner or an internal platform team publishing a reusable Data 360 blueprint, and the wrong tool for “just get my sandbox to prod.”

The failure mode is reaching for the packaging/2GP path for a simple environment promotion, then fighting managed-package versioning and namespace rules you never needed. If you own both orgs and you’re moving config between them, you almost certainly want the DevOps data kit. If you’re handing config to someone else’s org, you want the 2GP path. Decide that first; everything downstream depends on it.

The limitations that shape the plan

These aren’t footnotes — each one changes how you sequence a deployment, and hitting them blind costs you a day of confused debugging.

A package can’t mix Data Cloud and core metadata. If you include a data kit in a package, you can’t add other kinds of core platform metadata to that same package. Data 360 metadata and ordinary Salesforce metadata don’t co-package. In practice this means your release is two coordinated deployments — the Data 360 kit and the core metadata (the Apex, the Flows, the permission sets that consume the data) — not one. Sequence them, and remember that the consumers usually depend on the data model existing first.

Unlocked packages are out for Data Cloud. You can’t put Data 360 metadata in an unlocked package. The distribution path is 2GP managed, and part of the reason is that Data Cloud isn’t available in scratch orgs, which is where unlocked-package development normally lives. If your team’s delivery pipeline assumes scratch orgs and unlocked packages for everything, Data 360 is the exception you have to design around.

Dependency order is enforced, and it will reject you. You can’t publish a calculated insight before the DMO it references exists in the target. The kit bundles components so they deploy together, but the internal ordering still has to respect the dependency graph — insights after the objects they read, graphs after the objects they join. Build the kit so its contents resolve in order, or the deploy fails on a reference to something that isn’t there yet. This is the same discipline that mapping DLOs to DMOs teaches: the model’s dependencies are real, and deployment surfaces them.

Schemas must be synchronized first. A DevOps data kit deploys into a data space, and the data space with the same prefix name has to exist in both the source and the target org before you deploy. More broadly, keep the sandbox and production schemas synchronized ahead of a kit deployment — a mismatch between what the kit expects and what the target already has produces schema errors that read as cryptic until you realize the two orgs drifted. Treat “confirm the data spaces and schema line up” as step zero of any promotion, not a thing you discover mid-deploy.

A deployment sequence that works

Pulling it together, here’s the order we’d run a first sandbox-to-production Data 360 promotion:

1. Confirm the target is ready. Data 360 provisioned in production, the matching data space created with the same prefix name, and the schema reconciled with the sandbox. Do this before you build the kit.
2. Decide the kit type. Own both orgs and promoting? DevOps data kit. Distributing to orgs you don’t control? 2GP packaging data kit. This choice is upstream of everything.
3. Assemble the kit in dependency order — streams and objects first, then the transforms, calculated insights, and data graphs that depend on them.
4. Deploy the Data 360 kit via the CLI or the deploy flow, as its own release — separate from any core platform metadata, because they can’t co-package.
5. Deploy the core metadata that consumes the model — the Apex, Flows, and permission sets — as a coordinated second step, after the data model exists.
6. Wire the manual last mile by hand. Activation targets aren’t in the kit; configure them per org. Verify the streams actually ingest and the insights actually compute in the target before you call it done.
7. Watch the meter. A freshly promoted org that starts ingesting and computing insights starts consuming credits. Fold the new workload into your credit-optimization plan rather than discovering it on the Digital Wallet a month later.

None of these steps is exotic, but skipping any one of them is how a “quick promotion” becomes a week of rework.

The takeaway

Data Kits are the answer to a question every Data 360 project eventually asks and few teams plan for: how does this config leave the sandbox? The honest version is that Data Cloud metadata doesn’t ride the tools you’re used to, so you package it in a data kit — a DevOps data kit to promote across orgs you own, a 2GP packaging data kit to distribute to orgs you don’t. Know what the kit carries (streams, DLOs, DMOs, calculated insights, transforms, data graphs) and what it pointedly doesn’t (activation targets), respect the dependency order and the data-space and schema prerequisites, and treat the Data 360 release and the core-metadata release as two coordinated deployments rather than one. Do that and Data 360 stops being the thing you rebuild by hand in every environment and becomes part of the same disciplined delivery as the rest of your org. For multi-org estates, this is also the groundwork that makes patterns like Data Cloud One manageable instead of a copy-paste marathon.

Understanding the basics

What is a Data Kit in Salesforce Data 360?

A data kit is a container for related Data 360 metadata — data streams, Data Lake Objects, Data Model Objects, calculated insights, batch data transforms, and data graphs — that lets those components deploy together as a unit. It exists because Data Cloud metadata lives in a plane separate from core Salesforce metadata and can’t be moved by ordinary Change Sets or the standard metadata path. Many Data 360 components can’t be deployed on their own and must be packaged inside a data kit, which makes the kit the supported ALM primitive for Data Cloud rather than an optional convenience.

What’s the difference between a DevOps data kit and a packaging data kit?

A DevOps data kit migrates Data 360 metadata between orgs you own — typically sandbox to production — usually deployed through the Salesforce CLI, and it’s what most implementation teams need. A packaging data kit is embedded in a second-generation managed package (2GP) to distribute config to orgs you don’t control, such as an AppExchange or template scenario, where it unpacks after the managed package installs. Choose the DevOps kit for internal promotion and the 2GP kit for distribution; using the packaging path for a simple sandbox-to-prod move adds managed-package complexity you don’t need.

What can’t a Data Kit deploy?

Activation targets are not supported by data kits (neither 2GP nor the older 1GP path), so the last-mile push of a segment to an external destination stays a manual per-org setup. You also can’t put Data 360 metadata in an unlocked package, and a single package can’t mix Data Cloud and non-Data Cloud metadata — so your release becomes two coordinated deployments. Deployments also fail if dependency order is wrong (a calculated insight can’t publish before the DMO it references exists) or if the target data space or schema doesn’t match the source.

Why does my Data Kit deployment fail with a schema or data space error?

Usually because the source and target orgs drifted. A DevOps data kit deploys into a data space, and a data space with the same prefix name must exist in both the source and target org before you deploy. Beyond that, keep the sandbox and production schemas synchronized ahead of the deployment — if the kit expects a schema the target doesn’t have, or a referenced object isn’t present yet, you get schema-mismatch and unresolved-reference errors. Confirming the data spaces and schema line up is step zero of any promotion.

---

Standing up Data 360 and want the deployment path designed before you build, not after — data spaces, kit strategy, and the core-metadata coordination that trips teams up? Talk to us about Data Cloud and integration. Getting the ALM right is what keeps the foundation from being rebuilt by hand in every org.