A Different Space
Este conteúdo não está disponível em sua língua ainda.
Module 3 in the chapter Data 360 in One Picture, chapter 1 of the Data 360 Architect course. Each module stands on its own. Previous: Their Verbs and Ours · Next: What Data 360 Is, and Isn’t
The question this module answers: Where does Data 360 really live, why does it behave so differently from your core org, and which org should be its home?
You open Setup, you find Data Cloud Setup (the menus still use the old name; module 2), and it looks like part of your org. Same login, same Setup menu, list views like any other. It’s easy to assume it works like everything else you know. It doesn’t. You need to realize it’s in a different space. That space has a name: the tenant.
The tenant, and the screens in core
Section titled “The tenant, and the screens in core”Your Data 360 tenant is where Data 360 actually lives. The data you bring in, the lake, the model, and all the processing (the streams, the transforms, identity resolution, the insights) run in the tenant, not in your core org. Salesforce’s architecture guide describes it: Data 360 runs on Hyperforce, deployed on public cloud providers such as AWS, and stores its data in a lakehouse built on open formats (Apache Iceberg and Parquet). That’s a different engine from the core org’s database, with different limits and a different way of working.
What’s in your core org is the user interface. And that was one of the keys to Data 360’s success. Think about Heroku, Salesforce’s platform for running apps. Heroku has its own dashboard and its own accounts: a different login, different screens, a different place to learn. A company can sign people in to Heroku through Salesforce, with single sign-on, but only on Heroku’s Teams and Enterprise plans, and it’s still a separate place. With Data 360, Salesforce took a different path. They took the tenant engine and put its user interface inside core. So a Salesforce admin can set it up from the Setup menu, and core users work with it through tabs, list views and record pages they already know.
That’s a strength. It’s also where the confusion starts. People think they’re in core, but they’re not. When you open a data stream or a data model object, you’re looking through core’s screens at something that lives in the tenant.
So keep the two apart:
- The screens live in the home org. That’s where you log in, manage Data 360 and set up access.
- The data and the processing live in the tenant.
The home org and its tenant’s instance, on AWS in US East 2 (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size
What’s different
Section titled “What’s different”Most of us spent years learning the core org: sObjects, fields, validation rules, governor limits, change sets. The tenant sits beside that, and it behaves completely differently.
- The objects are different. People are used to sObjects. Then you have to talk about DSOs, DLOs and DMOs: the stream’s side, the lake, and the model. Module 1 walked through all three. They aren’t records you open and edit; they’re layers that data flows through.
- The limits and behaviors are different. The tenant has its own limits, its own timing and its own way of processing. What you know about governor limits doesn’t carry over.
- The cost is different. Data 360 is consumption-based. You pay as you use it, counted in credits. Module 5 gives the first habits; chapter 21 goes deep.
- Deployment is different. Moving Data 360 work from a sandbox to production is an extra phase, with its own tools. That’s chapter 22.
- Crossing between the two is an integration. When core reads from the tenant, it goes through its own authentication and an integration user. And not every core user needs Data 360 access. Most of them never will.
So the first job isn’t technical. You’ve got to train your team that it is a different space. If they treat it like one more set of custom objects, every later decision will surprise them.
Data spaces: partitions inside the tenant
Section titled “Data spaces: partitions inside the tenant”Inside the tenant there’s one more boundary to know from the start: the data space. Salesforce: “A data space is a logical partition to organize your data for profile unification, insights, and marketing in Data 360.” You can separate data, metadata and processes by brand, region or department, so that people see and work on data only in their own data space. In my words: it’s as if you had different divisions of a company, and you want to keep a strong separation.
Here’s what to know on day one:
- Every org starts with a default data space. “Until you create other data spaces, all Data Cloud objects are mapped to the default data space.” You can’t delete it. In Salesforce’s words, “users with standard permission sets are granted access to the default data space.”
- More data spaces need an add-on license. Help lists Data Spaces as “Available with add-on license.”
- Data reaches a data space through its lake objects. When you bring data in, you associate each data lake object with a data space, with or without filters, and one lake object can go into more than one data space. From there, each data space has its own model mappings, identity resolution, insights, segments and activations.
- That’s why the screens keep asking. When you deploy a stream, open Data Explorer or build a transform, you’ll be asked to choose a data space. In this course, that’s the default, unless I say otherwise.
A new org’s one data space: default (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size
My advice: stay on the default data space unless you need the separation. Every way into a data space other than the default takes an extra step: the APIs, Apex, SQL clients. I kept my own demo org in a custom data space on purpose, so I could learn the nuances. If you’re considering data spaces, learn those nuances first; otherwise stay on the default data space. It’ll work just fine, and you won’t have the extra steps.
Data spaces also matter across orgs: when other orgs share a tenant, the tenant shares data spaces with them (next section). And seeing a data space is something you’re given: a new Data 360 org starts with no access at all, and access is granted on purpose (module 5). Chapter 17 covers data spaces and access in depth, and chapter 21 how they affect credits.
The home org
Section titled “The home org”The tenant is provisioned on one org, the home org. Salesforce: “The Home Org is the org that Data 360 is provisioned on.” That’s where the screens are, where you log in, manage Data 360 and set up access. Any other production orgs that use the tenant connect as companion orgs.
What does a companion get? The home org shares data spaces with it, and nothing is copied. The companion org gets the description of the objects in each shared data space, its data model objects and calculated insights, and its users see and use that data where it sits, in the tenant. Salesforce says the shared objects can be referenced “with Data 360 features” and used “with platform features, such as Flow and related list enrichments.” In the companion org, those features come in an app called Data Cloud One. What a companion can’t do is bring data in through data streams of its own, or change what the home org owns. And the connection is always set up from the home side: “The connection must be initiated from the home org.”
Two ways to place the tenant, and the share: from the tenant out to each companion.
That’s the share. The data itself flows the other way. When the home org sets up a companion, Salesforce also connects to it as a source: “When you create a Data 360 companion connection, a standard Salesforce CRM org connection is also created.” So each org’s CRM data comes down into the tenant, the home org’s and every companion’s, like any other source (chapter 5).
The same orgs, the data flow. This is data flow, not connection: the data moves down, the share goes up.
Which org should be home? Here’s how I decide.
If you have one production org, that’s your home org. It’s where your people already log in and set up access. It just gravitates that way.
If you have more than one production org, separated by region or by function, the question is which one becomes the home org of your Data 360 tenant. You have two choices. You can choose one of them. Or you can stand up a new org whose only job is to manage Data 360. I call it a governance org. Then every production org is a companion.
You could also stand up a governance org when you have only one production org. There are benefits. But it means different logins and a different place to go, and that can add confusion. So one to one, I’d typically put it in your production org. The moment you have more than one, you choose one, or you put all your Data 360 management in its own governance org.
Salesforce’s provisioning guide for architects lands in the same place. It says an existing org works best for “customers with a single Salesforce org, or multi-org customers who already have a major centralized org where most business processes run.” Its main drawback: it “can inherit an existing org’s governance or technical debt.” A new, dedicated org works best for “customers with multiple Salesforce orgs who can’t align on a single major org, or enterprises with a strong Center of Excellence (CoE) model,” and you license a new org to get it. The guide calls the choice “a critical architectural decision with long-term consequences.”
When several orgs share one tenant, Salesforce’s architecture for that is called Data Cloud One (the name hasn’t changed with the Data 360 rename). In the architecture guide’s words, “Data 360 shares one or more of its data spaces with each companion org, providing access to both data and metadata in each shared data space.” Chapter 16 is all about it.
Watch it on video
Section titled “Watch it on video”In 2024 I filmed what it takes to work in a data space of your own: the permission set, and the extra step on every way in. And in 2026 I filmed core reading Data 360 live, crossing between the two with an integration user. The notes under the videos say what’s still right and what’s changed since.
What an architect decides here
Section titled “What an architect decides here”- Which org is the home org of the tenant: your one production org, one of several, or a governance org of its own.
- Whether you need any data space beyond the default, and if so, the boundary each one draws: brand, region or department.
- Who needs Data 360 access, and who never does.
- How you’ll train the team that the tenant is a different space before they design in it.
- How core and the tenant talk to each other: which integration user, with which permissions.
Explore
Section titled “Explore”Checked 2026-11-14.
- Data 360 Architecture (opens in a new tab), Salesforce Architects: the tenant on Hyperforce, the lakehouse, the home org and Data Cloud One.
- About Data Spaces (opens in a new tab), Salesforce Help.
- Data 360 Provisioning (opens in a new tab), Salesforce Architects decision guide: existing org versus a new, dedicated org, and Data Cloud One.
- Set Up a Data Cloud One Companion Connection (opens in a new tab), Salesforce Help: set up from the home org; what a shared data space shares.
- Data 360 Features on Companion Orgs (opens in a new tab), Salesforce Help: what a companion org can do in the Data Cloud One app.
- Set Up and Turn On Data 360 (opens in a new tab), Salesforce Help.
- Set Up Salesforce Identity SSO with Heroku (opens in a new tab), Heroku Dev Center (last updated May 30, 2024).