For organizations grappling with the complexities of managing data, metadata and insights across multiple Salesforce CRM orgs, Data Cloud One emerges as a beacon of balance between centralization and autonomy. By establishing a single Salesforce CRM org as a “home” Data 360 org and establishing “companion” connections with other Salesforce CRM instances, Data Cloud One provides a near-native Data 360 experience on multiple Salesforce orgs from a single Data 360 implementation. This opens exciting possibilities, but also introduces unique considerations for the Software Development Lifecycle (SDLC) and, crucially, for the use of Salesforce sandbox environments.
This blog post dives deep into how sandbox orgs – the bedrock of safe and iterative Salesforce development – function within a Data Cloud One ecosystem. We’ll explore typical sandbox workflows and highlight the nuances and recommendations specific to a multi-org setup leveraging Data Cloud One.
What is Data Cloud One?
Before we dive into the strategy for Data Cloud One on sandbox orgs, let’s take a minute to establish a baseline understanding of what Data Cloud One is and how it works.
Data Cloud One lets multiple Salesforce orgs share a single data 360, centralizing all your data so you can build a true customer 360 across all of your orgs.
In a Data Cloud One cluster, the org that Data 360 is provisioned on, is designated the home org. Bidirectional companion connections are established with other Salesforce orgs–designated companion orgs–to ingest their data into the home org’s Data 360 and to enable the most essential Data 360 functionality on the companion orgs. (For a deepdive into all the decisions and considerations that go into Data 360 provisioning across different architectures, do check out this extensive blog!)
The Data 360 home org takes care of foundational aspects such as ingestion, harmonization, and unification. Companion orgs can access Data 360’s metadata and data to power analysis and activation features. You can divide the features powered by Data Cloud One on a companion org into three broad groups.
- Data 360 features such as calculated insights, segments, and governance policies.
- Data 360-powered platform features such as Enrichments and Flows.
- Data 360-powered multi-cloud features such as Prospecting Center, Feedback & Audit Trail, and Agentforce Data Library.
With just one Data 360 to setup and manage, you accelerate your time to value, reduce administrative overhead, and provide a single source of truth across all of your orgs.
Understanding the Data Cloud One Sandbox Landscape
In a Data Cloud One world, your sandbox strategy must encompass both the Home org and the connected Companion CRM orgs. When you create sandboxes from your companion orgs, you need to understand how the sandbox orgs in your Data 360 cluster work. Each type of sandbox–Developer, Developer Pro, Partial Copy, and Full–retains its core characteristics regarding storage limits and refresh frequencies. However, each org’s role and interaction within the Data Cloud One cluster demand careful consideration.
Data Cloud One Cluster
This term refers to all of the orgs connected to a single Data 360 via Companion connections, including the home org and all of its companion orgs.
Sandbox Environments
Setting up different types of sandboxes allows you to make and test your changes (like, code, configurations, settings) as they move through the development cycle (writing, testing, fixing). When you’re creating sandbox orgs from a production org that is or will be a companion org, use-cases often require you to create sandboxes of home org as well.
In the diagram below, we show four different environments. Each sandbox environment contains one sandbox org created from its production org. Changes made in the development environment are moved through two levels of QA before being added to the production orgs, ensuring a smooth rollout.
Recommended best practice is to maintain clear demarcation between production and sandbox environments when it comes to companion connections. This protects you from violating data integrity, security and compliance risks, disruption of the software development lifecycle, and other adverse effects. In order to ensure that this demarcation is always in place, we allow only the following,
- A Sandbox home org can only establish a companion connection with sandbox CRM orgs.
- A Production home org can only establish a companion connection with production CRM orgs.
Home Org Sandboxes
Data Cloud One home org sandboxes function much like standard Salesforce org sandboxes, but with a couple of important differences.
First, Data 360 isn’t automatically enabled in your sandbox. You’ll need to manually turn it on.
Second, while your Data 360 metadata is copied to the sandbox, your Data 360 data isn’t. If you aren’t familiar with metadata, think of it as a description of your data. For example, the configuration for a calculated insight is metadata, and is copied to your Data 360 sandbox. However, the output data from the calculated insight that exists in your production Data 360 isn’t copied to your sandbox. This means that your sandbox Data 360 replicates your data streams, data model objects, calculated insights, segments, and so on, but they don’t contain any data.
Finally, the home org in a Data Cloud One cluster is different from a standalone home org in that it has connected companion orgs which are dependent upon it for access to Data 360 metadata. It’s important to be mindful of the implications of this dependency.
Companion Org Sandboxes
Sandboxes created from your Data Cloud One companion org behave like regular CRM org sandboxes, allowing you to use, develop and test platform features (Apex, flows, reports, etc.) as well as leverage the companion connection to the home org sandbox to work with Data 360 features (calculated insights, segments, etc), as well as Data 360 powered features.
Key Steps in the Data Cloud One Sandbox Journey
With the context set, let’s walk through what you need to consider when you’re planning and setting up a Data Cloud One cluster of sandbox orgs.
Prerequisites
No matter what you’re doing in Data 360, it’s critical to plan your approach before you take any actions. While this may seem time consuming, building the right architectural foundation saves you from needing to backtrack and clean up mistakes later.
Perform Metadata Clean-Up If Needed
The core principle is to make sure that unnecessary Data 360 metadata is not already present in the org that you are trying to connect as a companion org. Depending on how you created your org, you may have inadvertently violated this principle, and you may need to clean up old Data 360 metadata. An example scenario is explained below,
Let’s understand what happens under the hood that might trigger this prerequisite.
- When you connect any CRM org (say, Org 2) as a companion org to a Data 360 home org (we’ll call it Org 1), some essential Data 360 metadata copies over to this companion org. This metadata is supposed to be copied over as part of the companion connection, not before it.
- If you create the sandbox of Org 2 after making the companion connection in the production environment, this Data 360 metadata also copies over to the Org 2 sandbox.
- You can’t connect an org as a companion org if it already has Data 360 metadata on it, as this would lead to metadata conflict issues. Since your sandbox copy of Org 2 already has Data 360 metadata from the production org, you’ll get an error if you try to connect it as a companion org in your sandbox environment. You will presently have to perform metadata clean-up as discussed below. (We’re hoping to make production metadata reusable in the future, but at this time, you can’t reuse it.)
- Let’s talk about how to approach the metadata cleanup. Originally, metadata cleanup could only be completed by the Salesforce Engineering team, which was a tedious process for everyone involved. We didn’t like it any more than you did, so we started rolling out self-serve metadata cleanup in August 2025. If your org has already received the update, you can find the cleanup tool in Data 360 Setup when you don’t have an active Data 360 license. Instead of waiting weeks for an engineer to clean up your orgs for you, you can now click a couple buttons and have your org cleaned up within about an hour. Follow these steps to clean up the unnecessary Data 360 metadata.
Just to reiterate a consideration in the current state – To avoid the extra step of metadata cleanup, preferably create your sandbox orgs before connecting your production org as a companion org.
Licensing Considerations
- Home Org Considerations
By default, your Data 360 Home org can make companion connections to three eligible CRM orgs for free. If you want to connect more than three orgs as companion orgs to a single Data 360 home org, you’ll need to buy an adequate number of “Data Cloud One Additional Connection licenses” and add it to the Home org. For example, suppose you want to connect 5 companion orgs to the same Home org. Three of the companion orgs can be connected without needing extra licenses. You then need to buy 2 more “Data Cloud One Additional Connection licenses” and add them to your Home org.
You can add Data Cloud One Additional Connection licenses to your production home org in Your Account. When you create your Home Org Sandbox after this step, these licenses copy over to your Home Org Sandbox as well, and you are good to go. (In case the steps were done in reverse order, please ensure to perform license match to your Home Org Sandbox so that the necessary licenses copy over).
- Companion Org Considerations
Each org you’re connecting as a companion org must have a Data Cloud Companion license. Follow relevant paths from the list of paths below to get the Data Cloud Companion license on to the sandbox CRM org you intend to connect as a companion. For the CRM org that you intend to use as a companion,- If you’re yet to create sandbox orgs, add Data Cloud Companion licenses to your production org and then create sandbox orgs. Your production licenses automatically copy over to the sandbox orgs.
- If you’ve already created the sandbox org before adding the Data Cloud Companion license to the production org, you have two choices. Add the companion license to the production org and then,
- Use license match to update the prospective sandbox companion org (OR)
- Perform an org refresh on the prospective sandbox companion org. The refresh ensures that the new sandbox org gets the Data Cloud Companion license copied over from the production org. We don’t recommend this route unless you were already intending to refresh the org for some other reason.
Review Gotchas
Your sandbox org strategy should keep these considerations in mind.
- You can’t create cross-environment connections.
To ensure that there’s a clear demarcation between production and lower environments, a production org can only be connected to other production orgs and a sandbox org can only be connected to other sandbox orgs. This protects you from violating data integrity, security and compliance risks, disruption of the software development lifecycle, and other adverse effects.
- Be careful about refreshing sandbox orgs in the Data Cloud One cluster.
The cluster is a closely knit network. Plan ahead and follow recommended best practices to avoid any ripple effects. As a rule of thumb, it’s best to perform planned disconnects of the orgs in case any unavoidable refresh is lined up. When a sandbox is refreshed, it is completely destroyed and a new sandbox org with a new org ID is created. If a sandbox org does get refreshed without proper prior disconnection of the companion connection, it would presently require intervention from Salesforce team to clean up the dangling connection.
Setup Steps
Once you’ve completed the prerequisites, you’re ready to set up your Data Cloud One sandbox cluster.
Step 1: Create Your Sandbox Orgs
Follow the documented instructions to create a Data 360 sandbox—but before you do, think about these three aspects.
- Decide what type of sandbox you need.
The type of sandbox you should create will depend on what it’ll be used for. If you’re setting up sandboxes for an individual to develop code, a developer org might be most appropriate. But if you’re planning integration testing or UAT, partial or full copies might be best. - Consider dependencies between your connected orgs.
Before creating your sandboxes, consider dependencies between your orgs. For example, if you already have a sandbox copy of your home org, its intended refresh cycle may not align with the intended refresh cycle of the connected companion orgs - Plan the setup order for your orgs.
If you’re setting up a series of new sandboxes, plan the order in which you’ll create or refresh them. Sandboxes aren’t provisioned instantly, and you may need to create or refresh orgs in a specific order to ensure that connections can be properly established and metadata is properly populated.
Step 2: Connect your Sandbox orgs
Make sure you’ve reviewed and completed licensing and metadata cleanup prerequisites highlighted in the previous sections. After this, the process of connecting the orgs is pretty much the same as you would have experienced in the production environment as well.
It’s likely that for any given companion production org (Org 2), you might create multiple sandbox copies (E.g. Org 2 Sandbox Dev, Org 2 Sandbox QA1, Org 2 Sandbox QA2, and so on). Each type of environment must have its own home org and companion orgs, mirroring the production environment. For example, since the production environment only has 1 version of Org 2, each other environment (dev, QA1, QA2) , should only have one Org 2 Sandbox with a companion connection to the Home Org Sandbox of that environment.
Be mindful of the CRM connection alias that could have carried over from the production org, and the appropriate steps to handle it.
Step 3: Populate Your Sandboxes with Data
You may remember from our discussion of the Data Cloud One landscape that Data 360 data won’t get copied into your sandbox org. Data 360 sandboxes only include your metadata, and you won’t be able to test your builds without data.
You could populate your sandbox orgs with data by setting up connections and ingesting all your real data into your sandbox org, just like you ingest it into your production org–but that’s expensive and usually unnecessary.
Instead, we recommend populating your sandbox org with representative data rather than your real data. You only need enough data to test the results of any calculated insights, segments or other features you’re planning to build in your sandbox.
With data added, you’re ready to use your companion org sandboxes to build features and test configurations that rely directly or indirectly on Data 360 metadata.
Step 4: Build and Test
Your sandbox orgs are now ready for you to use as your playground for developing and configuring new features. You can use multiple sandbox environments to test your changes with different sets of data before rolling them out on your production orgs.
Step 5: Deploy Your Metadata
You’ll need to deploy in different ways depending on data dependencies and what type of org you’re deploying to.
- If you’re considering deployment from Data 360 home org, you can deploy metadata between sandbox and production orgs with data kits.
- If you’re considering deployment from a connected companion org, you can approach the scenarios in the following manner.
- To deploy metadata that isn’t dependent on Data 360, you can choose between change sets, Salesforce CLI, unmanaged packages etc.
- Deploying metadata that’s dependent on Data 360 is a bit trickier. Right now, the only type of Data 360 metadata you can create through the Data Cloud One app on a companion org is “Calculated Insights” metadata. However, you might have set up Data 360 powered features like a flow that references a data model object. When you’re deploying metadata with a Data 360 dependency, you should be mindful of deploying it in the appropriate sequence.
Key Takeaways
Prep Your Orgs to Become Companion Sandbox Orgs
Home Orgs and Companion Orgs have different licenses—be careful to ensure each org in your planned Data Cloud One cluster has the appropriate license. You can’t make an org as a Data Cloud One Companion Org if it has a Data 360 license or leftover Data 360 metadata or if it doesn’t have the Data 360 Companion license.
Plan Your Setup Before You Start
Plan the order you’ll set up and connect your orgs before you set up sandboxes. There are some temporary considerations you have to keep in mind until the enhancements listed in the next point are available. These considerations include aspects such as,
- Preferably create your sandbox orgs before creating companion connections between production orgs. (In the current state, this helps you avoid additional clean-up steps)
- If your production orgs are already connected prior to setting up sandbox orgs, you’ll need to clean Data 360 metadata off the sandbox orgs created from production companion orgs and only then you can connect them to the sandbox home org
Exciting Enhancements Coming Up!
Previously, the Data 360 metadata copied from the production companion org presented a cleanup issue, making reuse and building upon it impossible. A forthcoming enhancement addresses this: it will allow you to connect the Home and Companion Sandboxes without requiring a metadata cleanup on the Companion Sandbox. Critically, you will then be able to immediately reuse and build upon the existing metadata once the connection is successfully established. This is one of several critical enhancements that are coming up!
Conclusion
Salesforce Data Cloud One presents a compelling solution for multi-org data unification, but you’ll need to plan ahead before creating sandboxes of the orgs in your Data Cloud One cluster. Sandbox orgs give you a playground for the robust integration testing and coordinated deployments that are crucial for success. By understanding metadata behavior and dependencies between orgs, you can establish clear processes and navigate the sandbox maze to unlock the full potential of Data Cloud One.
Written by
