3.2 Data Spaces Architecture, Resource Allocation & Tenant Isolation

Data Spaces Architecture, Resource Allocation & Tenant Isolation

Enterprise organizations frequently operate multiple brands, subsidiaries, geographic business units, or autonomous divisions. Historically, achieving strict data and operational separation required deploying and maintaining multiple independent Salesforce orgs or customer data platform instances. This approach resulted in duplicated integration pipelines, fragmented customer identities, and exorbitant licensing and infrastructure costs.

In Salesforce Data Cloud, Data Spaces solve this challenge by providing logical multi-tenant partitioning within a single Data Cloud tenant. A Data Space acts as a secure perimeter that segregates data, metadata, processing logic, and user access while preserving the economies of scale and shared governance of a centralized lakehouse.

---

The Default Data Space vs. Custom Data Spaces

Every Data Cloud instance is provisioned with a foundational partition known as the Default Data Space:

• Default Data Space: Created automatically upon org provisioning. All legacy data streams, data lake objects (DLOs), data model objects (DMOs), identity resolution rulesets, and calculated insights created before configuring custom spaces reside here. The Default Data Space serves as the central clearinghouse from which core canonical schemas and global data assets can be managed.
• Custom Data Spaces: Created by a Data Cloud Architect to represent discrete business entities (e.g., "Brand_Luxury", "Brand_Hospitality", "Region_EMEA", "Commercial_Banking"). When users log in, their session context is scoped to the Data Space(s) to which they are assigned, preventing unauthorized visibility into other divisions.

---

Component Assignment & Sharing Across Data Spaces

Data Spaces govern how assets and resources are partitioned or shared across the enterprise data lifecycle. Understanding how individual components behave when associated with a Data Space is critical for both the certification exam and real-world solution design.

1. Data Streams & Data Lake Objects (DLOs)

Data Streams ingest raw data from source systems. A Data Stream can be created directly within a custom Data Space or created within the Default Data Space. The resulting Data Lake Object (DLO) remains tied to the Data Space where the stream originates.

2. Data Model Objects (DMOs) & Row-Level Filtering

While DLOs are tightly bound to their ingestion stream, Data Model Objects (DMOs) can be shared from the Default Data Space to one or more custom Data Spaces. This enables an enterprise to define a standardized canonical Customer 360 data model once and make it available across all business units.

Crucially, when sharing a DMO to a custom Data Space, administrators can apply a Data Space Filter:

• A Data Space Filter is a row-level filter predicate based on field values (e.g., Brand_Identifier__c = 'Luxury' or Country_Code__c = 'GB').
• When users or processes query the shared DMO within that custom Data Space, they only see records that satisfy the filter predicate.
• This provides ironclad row-level security without duplicating underlying physical data storage.

3. Identity Resolution Rulesets

Crucial Exam Concept: Identity Resolution Rulesets belong strictly to a specific Data Space. Identity resolution does not run across Data Spaces. Each Data Space maintains its own independent rulesets, match criteria, and reconciliation rules.

If the same consumer interacts with two different brands configured in separate Data Spaces:

• In Data Space A, the consumer resolves to Unified Individual A based on Brand A's match rules.
• In Data Space B, the consumer resolves to Unified Individual B based on Brand B's match rules.
• The two profiles remain completely isolated. Data Cloud does not merge them across Data Space boundaries.

4. Calculated Insights & Streaming Insights

Calculated Insights are authored within a specific Data Space and calculate multidimensional metrics strictly across the data visible within that Data Space. An insight created in Data Space A cannot reference records or tables from Data Space B. If an enterprise requires global metrics (e.g., total cross-brand spend across all subsidiaries), that Calculated Insight must be built within the Default Data Space where unfiltered enterprise data is accessible.

5. Segments & Segmentation Canvas

Segments are strictly scoped to the Data Space in which they are constructed. When a marketer opens the Segment Canvas in the "EMEA" Data Space, the attribute catalog only displays DMOs, attributes, and Calculated Insights assigned to "EMEA". A marketer cannot build an audience filter that references data from another Data Space.

6. Activation Targets & Activations

Activation Targets (e.g., Marketing Cloud Business Units, external Amazon S3 buckets, Google Ads accounts) can be assigned to one or more Data Spaces. An activation created within a Data Space can only deploy audience payloads to Activation Targets that have been explicitly associated with that Data Space.

---

Component Assignment Behavior Matrix

The following reference table summarizes how Data Cloud components operate within the Data Spaces architecture:

---

User Access & The Data Space Switcher

User access to Data Spaces is administered through standard Salesforce Permission Sets combined with Data Space assignments:

1. Data Space Assignment: Administrators assign users to one or more Data Spaces based on their job responsibilities.
2. Role Combinations: A user's functional capabilities can vary by Data Space. For example, a user can be granted Data Cloud Activation Manager rights in the "Americas" Data Space but only Data Cloud User (read-only) visibility in the "APAC" Data Space.
3. The Data Space Switcher: When a user assigned to multiple Data Spaces logs into Data Cloud, a dropdown selector appears in the global navigation bar. Selecting a Data Space dynamically filters all application tabs, records, segments, and insights to that specific workspace. Users assigned to a single Data Space do not see the switcher; their session is locked to their designated workspace.

---

Resource Allocation, Quota Consumption & Governance

A common architectural misconception is that Data Spaces allocate partitioned resource quotas (such as capping Brand A at 1 million credits and Brand B at 500,000 credits).

Data Cloud does not enforce hard quota partitions per Data Space. All Data Spaces within a tenant draw from a single, shared pool of tenant entitlements:

• Data Services Credits: Consumed globally by ingestion, batch data transforms, and calculated insights.
• Segment Processing: Segment refresh cycles consume tenant-wide processing capacity.
• Storage: Data lake storage is aggregated across all Data Spaces.

Because resource consumption is pooled, enterprise architects must establish centralized governance. Administrators should leverage Data Cloud Usage Reports, Salesforce Digital Wallet, and Audit Logs to monitor consumption patterns across business units and prevent a single division from monopolizing tenant processing capacity.

---

Architectural Decision Matrix: Single-Org Data Spaces vs. Multi-Org Topology

When designing enterprise architecture, consultants must evaluate whether to use a single Data Cloud org with Data Spaces or deploy multiple independent Data Cloud orgs.

The Golden Architectural Rule

Use Single-Org with Data Spaces whenever business units operate under shared corporate governance and data can legally reside in the same geographic cloud region. Reserve Multi-Org Topologies strictly for scenarios involving legally separate corporate entities, distinct billing ownership, or strict data residency mandates requiring physical isolation across different Hyperforce regions.