Data spaces in Data 360

The first time you open Data 360 and see a dropdown labelled “default” in the corner of the screen, it reads like a workspace picker — a convenience for keeping your objects tidy. Teams treat it that way for months: everything lands in the default data space, and nobody thinks about it again until two brands share a customer, or a regional team asks why they can see records they legally shouldn’t, or an agent grounds an answer on data from a business unit it was never meant to touch.

A data space is not a folder. It’s a logical partition for profile unification, insights, segmentation, and activation — one of the load-bearing architectural decisions in a Data 360 implementation, and one of the few that’s genuinely painful to change after you’ve built on top of it. Get it right and you run several brands, regions, or business units inside a single org with clean boundaries between them. Get it wrong and you either leak data across teams that should be separated, or you fragment a customer view that should have been whole.

This post is the practitioner’s map of data spaces as they work in mid-2026: what a data space actually scopes, why identity resolution is the boundary that matters most, how the enhanced-security permission model changed the access story, and how to make the one-versus-many call before it hardens into something expensive to unwind. If you’re still getting oriented on the platform itself, what is Salesforce Data 360 is the primer this builds on.

What a data space actually scopes

Every Data 360 org is provisioned with a single default data space, and until you create another, everything you build lives inside it. That’s why data spaces feel invisible at first — you’re already in one and never had to choose it.

When you do create additional data spaces, a lot more than folders comes with each one. A data space is the container for the objects and metadata that define a customer view:

Data Lake Objects (DLOs) and Data Model Objects (DMOs) — the raw ingested data and the mapped, harmonized model on top of it
Object mappings from source data to the canonical model
Identity resolution rulesets — the match-and-reconcile logic that fuses records into unified profiles
Calculated insights, segments, data actions, and activation targets

The consequence hiding in that list is the whole point of the feature: because identity resolution rulesets live inside a data space, unification happens within a data space, not across them. Two records that would merge into one unified profile in the same data space stay separate if they live in different data spaces. That’s a feature when your two brands are legally or commercially distinct and must not share a customer graph. It’s a bug you built yourself when the same human is a customer of both brands and you needed one view of them.

A data space is where you decide who is allowed to become the same person. Everything else it separates is downstream of that one choice.

This is why data spaces and identity resolution have to be designed together, not sequentially. If you haven’t tuned match rules before, our guide to identity resolution that doesn’t over-merge is the companion to this decision — the ruleset and the partition it runs in are two halves of the same architecture.

The access model changed — know which one you’re on

The other thing a data space governs is who can see what, and this is where teams carrying older mental models get tripped up. The access story was reworked, and the modern model is materially different from the early one.

Historically each data space came with its own permission set, and you’d assign users to the space’s permission set to grant access. Under the enhanced security model — rolled into standard Data Cloud orgs from April 2024 — data space access control is integrated into permission sets directly, and the pattern inverted. Now an admin can associate multiple data spaces to a single permission set, and use feature permissions to further restrict which data-space-aware features a user can touch within that permission set. The blunt “one permission set per space” era is over; the current best practice is granular feature permissions layered onto permission sets you associate with the spaces they should reach.

Two specifics worth internalizing because they change how you grant access:

Salesforce removed the View All Records and Modify All Records object permissions on DLOs from the standard Data Cloud User, Marketing Manager, and Marketing Specialist permission sets. Broad DLO visibility is no longer something a standard permission set hands out by default — you grant it deliberately by associating a permission set with the data space where the DLO lives.
The Data Cloud Architect permission set still carries full access across every data space and nearly every Data 360 capability. Treat it the way you’d treat Modify All Data in core Salesforce: a small number of named people, not a convenience you spray across the team.

If you’re auditing who can reach what, the discipline here is the same one we argue for in going beyond the Health Check score — the tool tells you a setting is on; only a human review tells you whether the right people are on the right side of the boundary.

The one-versus-many decision

Here’s the call that determines whether data spaces help you or haunt you: how many do you create, and on what axis do you split? The instinct to spin up a data space per team is almost always wrong, because every boundary you draw is a boundary a unified profile cannot cross. Fragment too aggressively and you’ve rebuilt the data silos you bought Data 360 to eliminate.

The honest heuristic: split on a boundary that must not be crossed, not on a boundary that’s merely tidy. A few axes that genuinely warrant separate data spaces:

Distinct legal entities or brands that must not share a customer graph — a holding company whose subsidiaries are separately regulated, or brands where combining customer data would breach the consent under which it was collected.
Data residency or regulatory regimes — a region whose data cannot legally commingle with another’s. Here the partition isn’t a preference, it’s a compliance requirement.
A genuine test-vs-production or partner-isolation need within one org, where workloads must stay demonstrably separate.

And the axes that usually should not split, because you’ll regret losing the unified view: individual teams, marketing campaigns, product lines sold to the same customer, or “we might want to separate this someday.” Those are access-control problems, and access control is exactly what the permission-set-and-feature-permission model above is for. You can restrict visibility without sacrificing unification — reach for a permission boundary before you reach for a data-space boundary.

One practical constraint to factor in: data spaces are a capacity you provision, and edition limits apply — a Developer org, for example, is limited to a single data space, so you can’t fully rehearse a multi-space topology there. Check the current Data 360 limits and guidelines for the ceiling on your edition before you design a topology that assumes headroom you don’t have.

Where data spaces meet agents and activation

Two downstream systems inherit whatever boundary you draw, and both amplify the cost of getting it wrong.

Activation. Segments and activation targets are scoped to a data space, so an audience you build in one space can only activate from the profiles unified within it. If your paid-media activation needs the combined view of a customer across two brands and you’ve split those brands into separate data spaces, the combined audience simply doesn’t exist to activate — you partitioned it out of reach upstream.

Agent grounding. This is the one that surprises people in 2026. When you ground an Agentforce agent on Data 360, it retrieves from the data space it’s pointed at. Split your data across spaces and an agent sees only its slice — which is correct and desirable when a brand’s agent should never surface another brand’s customer, and a silent quality failure when the agent needed the fuller context to answer well. If you’re grounding agents, design the data-space boundary and the grounding scope together; the semantic layer that keeps agents from inventing your metrics still only governs metrics within the space the agent can reach.

Because data spaces multiply the objects, rulesets, and processing you run, they also touch consumption. Every data space with its own identity resolution and calculated insights is running its own share of the billable operations we break down in the Data 360 pricing guide — another reason not to create spaces you don’t need. If your bill is already climbing, the credit-optimization playbook is the place to start.

Takeaways

A data space is a partition, not a folder, and the partition it enforces is identity resolution — profiles unify inside a data space and never across one. That single fact should drive the whole decision. Design your data spaces and your match rules together, split only on boundaries that legally or commercially must not be crossed, and reach for the enhanced-security permission model — permission sets associated with multiple spaces, refined by feature permissions — whenever the real need is restricting visibility rather than preventing unification. Everything downstream, from paid-media activation to agent grounding, inherits the boundary you draw, so draw as few as the requirements demand and no more. This is the kind of foundational modelling we get right up front in our integration and Data Cloud work, because it’s the layer that’s cheap to design and expensive to re-cut.

Understanding the basics

What is a data space in Salesforce Data 360?

A data space is a logical partition in Data 360 for profile unification, insights, segmentation, and activation. Every org starts with one “default” data space, and additional ones let you separate data and metadata — DLOs, DMOs, identity resolution rulesets, segments, and activation targets — by brand, region, or business unit without standing up a separate org. The defining property is that identity resolution runs inside a data space, so records only unify into a single profile within the same space.

Should I use one data space or several?

Use as few as your requirements demand. Create separate data spaces only for boundaries that must not be crossed — distinct legal entities or brands that can’t share a customer graph, or data-residency regimes that can’t commingle. For merely wanting different teams to see different data, use the permission-set and feature-permission access model instead, which restricts visibility without sacrificing the unified customer view. Splitting too aggressively rebuilds the silos Data 360 exists to remove.

How do permissions work with data spaces now?

Under the enhanced-security model rolled out from April 2024, data space access is integrated into permission sets: an admin associates one or more data spaces with a permission set and uses feature permissions to refine which data-space-aware features a user can access. Salesforce also removed View All / Modify All on DLOs from the standard permission sets, so broad data-lake visibility is now granted deliberately rather than by default. The Data Cloud Architect permission set retains full cross-space access and should be tightly held.

Designing a Data 360 foundation that has to serve multiple brands or regions without leaking or fragmenting the customer view? Talk to us — getting the partition right the first time is exactly the work we do.