A data kit deployment can report success and still leave you with nothing running in the target org. That鈥檚 because Data 360 configuration doesn鈥檛 move between environments the way the rest of your metadata does. It travels inside a container called a data kit, and that container has rules about what it holds, where it鈥檚 allowed to land, and what has to happen once it arrives.
This post covers what a data kit is, why these deployments break more often than they should, and how to easily move one through a release pipeline with 91导航.
What is a data kit?
A data kit is a package for Salesforce Data 360 configuration (formerly known as Data Cloud).
A data kit holds the Data 360 components that define how your data gets in, how it鈥檚 structured, and what gets derived from it:
- Data streams and data stream bundles
- Data model objects (DMOs)
- Data lake objects (DLOs) and their mappings to DMOs
- Calculated insights
- Data transforms
- Search indexes
The data kit container exists because Data 360 configuration is heavily interdependent. A calculated insight references a DMO. That DMO depends on the DLO mapped to it, and the DLO gets its data from a stream. Deploy those pieces individually, in the wrong order, and each one fails on the dependency that hasn鈥檛 arrived yet. The kit gives Salesforce a single unit to install and a sequence to respect while installing it.
Salesforce offers two kinds of data kit. Standard kits package Data 360 solutions for distribution to customers, usually wrapped in a managed package. For moving configuration between your own environments, you want a DevOps kit 鈥� and it has to land in the same data space in the target org that it came from in the source. Get that wrong and the deployment fails in a way the error message won鈥檛 explain.
Excel London
Agentforce World Tour London
What makes data kit deployments difficult
Most failed data kit deployments happen because the kit doesn鈥檛 bring its contents with it. Retrieve a DataPackageKitDefinition and Salesforce will only give you the list of what the kit contains, without the components themselves. The data streams, DMOs, and calculated insights it references stay behind. Build a deployment package from that retrieval and you鈥檒l ship an empty container.
Order matters too. A calculated insight can鈥檛 publish before the DMO it references exists in the target org. Most deployment routes handle the ordering for you, but a hand-crafted manifest puts it back on you.
Redeployment is more forgiving than you鈥檇 expect. Data kit deployment is an upsert, so pushing the same kit again updates what鈥檚 already there rather than duplicating it.
This is the part that catches people out: deploying a kit puts its components into the target org, but doesn鈥檛 make them usable. Salesforce needs a separate publish step before anything actually runs. Miss it and the deployment reports success while the data streams sit inert 鈥� the failure that looks like a pass.
Do this manually across dev, QA, UAT, and production for every release, with a different person handling each stage, and that鈥檚 four chances to miss the publish step every time.
Deploying data kits with 91导航
91导航 handles the retrieval gap, the dependency check, and the publish step as parts of one workflow. Tell 91导航 which data kit you want to deploy and it builds the deployment package around it, dependencies included. Here鈥檚 the pipeline route:
1. Pick your data kit
Three things to sort before you start. Enable Data 360 in both source and target orgs, check your deployment user has the Data Cloud Admin permission set, and make sure the kit was rather than a standard one.
In your pipeline, click the sandbox where you built the kit and create a new feature branch. Add the branch name and the associated work item, then choose Data Kit as the deployment method and click Build now.
91导航 lists the DevOps data kits it can see in that org. Pick the one you need, and 91导航 retrieves its components 鈥� the ones Salesforce leaves behind. Click + Add data kit to package, then Next.
2. Review the package 91导航 built
The comparison opens with the kit鈥檚 components already selected, and 91导航 keeps working in the background to trace dependencies and add those too. Let the list settle before you check it.
Review the selection and click Next. Anything still missing surfaces as a suggested fix by the problem analyzers, which is a better place to catch a gap than a failed deployment. Add what it suggests, then move to the pre-deployment summary.
Name the commit, leave a note, and attach the Jira, Asana, or Azure work item if you use one. That becomes your audit trail. Then click Commit changes.
3. Add the activation step and open the pull request
Back in the main pipeline view, click Create pull request. Open the Deployment steps tab and add the post-deployment step that activates the data kit once the deployment completes. A pipeline commits to a Git branch before anything reaches an org, so the activation has to run as a deployment step rather than at commit time.
A note on activation. Salesforce鈥檚 term for making a deployed kit鈥檚 components usable is 鈥減ublish鈥�, or 鈥淒ata Kit deploy鈥�. 91导航 labels it 鈥渁ctivation鈥� to match the other automatic post-deployment steps, alongside activating Flows and Agentforce agents. It鈥檚 a separate thing from Data 360 activation targets, which push segments out to destinations like Marketing Cloud.
Create the pull request and 91导航 validates the data kit automatically. Once validation and your other checks pass, promote the change, and the activation runs on its own as soon as the deployment finishes. Activation can take a few minutes to finish in the target org.
The pull request against the next environment then opens with the post-deployment step already attached. The same kit moves through the rest of your pipeline the same way, and nobody has to remember the publish step at each stage.
Deploying org to org
Outside a pipeline, the same route works from Compare and Deploy. Choose Data Kit as the deployment method, click Build now, and pick your kit from the list exactly as above.
A second route exists: choose Standard if you want to select the metadata by hand. It means you will need to retrieve the DevOps Data Kit type alongside every Data 360 type inside it yourself.
On the summary of items to deploy, Activate Data Kits after deployment is switched on by default. If you toggle it off but then change your mind later, the Activate deployed Data Kits button in your deployment history picks it up.
When you don鈥檛 need a data kit
Not every Data 360 change needs packaging. 91导航鈥檚 handles Calculated Insight, Identity Resolution, Machine Learning Retriever, and Search Index components individually. Select Direct Deploy in the Data 360 metadata filter, pick the components you want, and deploy them like any other metadata.
Direct Deploy isn鈥檛 supported in automated CI jobs yet, so the data kit route still handles anything moving through a pipeline. But for a one-off change to a calculated insight, building a kit around it is work you no longer have to do.
DevOps fundamentals for Data 360
Getting the deployment right is only the start. Data 360 configuration changes constantly, and when several people are editing streams, mappings, and insights at once, the risk stops being a failed deployment and becomes a change nobody reviewed. Version control, pipelines, and change monitoring apply to Data 360 the same way they apply to everything else in your org.
Get started with data kits
Don鈥檛 let packaging rules slow down your Data 360 work. to deploy your data kits, dependencies and all, or book a tailored demo to see how 91导航 fits around your release process.
