Study guide
3.2 Data Spaces Architecture, Resource Allocation & Tenant Isolation
Salesforce Certified Data 360 Consultant formerly Data Cloud Consultant
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Solution Overview & Enterprise Value
1.1 Enterprise Customer 360 & Data Cloud Business Value 1.2 Architectural Foundation: Zero-Copy, Hyperforce, Lakehouse & Data Pipeline 1.3 Platform Terminology, Core Entities & Data Lifecycle Stages 1.4 Data 360's Foundational Role in Predictive & Generative AI
2 Chapter 2: Ethics, Privacy & Governance Fundamentals
2.1 Regulatory Compliance, Data Privacy & Ethics in Customer Data 2.2 Consent Management & Preference Enforcement in Data Cloud 2.3 Data Retention, Deletion, and Privacy Right-to-be-Forgotten (RTBF)
3 Chapter 3: Security, Permissions & Tenant Architecture
3.1 Standard Permission Sets, User Roles & Functional Access 3.2 Data Spaces Architecture, Resource Allocation & Tenant Isolation
4 Chapter 4: Administration, Monitoring & Lifecycle Management
4.1 Data Kits & Package Automation for Cross-Org Deployment 4.2 Auditing, Status Monitoring, Error Logs & Data Explorer 4.3 Sandboxes, Change Management & Metadata Deployment
5 Chapter 5: Ingestion Connectors & Source Integration
5.1 Standard Bundles & Salesforce CRM Connectors (Sales/Service/Marketing) 5.2 Cloud Storage (S3, GCS, Azure Blob) & Streaming Ingestion (Web/Mobile SDK, Ingestion API) 5.3 Zero-Copy Data Federation & Snowflake/BigQuery/Databricks Sharing
6 Chapter 6: Data Lake Objects (DLO) & Data Transformations
6.1 DLO Configuration, Primary Keys, Event Time & Data Stream Categories (Profile, Engagement, Other) 6.2 Streaming & Batch Data Transforms: Formula Fields, SQL Transforms & Data Prep Recipes
7 Chapter 7: Data Model Objects (DMO) & Canonical Harmonization
7.1 Customer 360 Canonical Data Model & Subject Areas 7.2 DLO-to-DMO Mapping Patterns, Cardinality & Custom DMO Design 7.3 Data Validation, Schema Maintenance & Field Mapping Best Practices
8 Chapter 8: Identity Resolution Architecture & Match Rules
8.1 Identity Resolution Concepts, Consolidation Rate & Graph Modeling 8.2 Match Rules & Match Criteria: Exact Match vs. Fuzzy Matching (Deterministic & Probabilistic) 8.3 Multi-Party Identification, Anonymous-to-Known Transitions & Contact Point Matching
9 Chapter 9: Reconciliation Rules & Unified Profile Governance
9.1 Reconciliation Rules: Most Frequent, Source Priority & Last Updated 9.2 Unified Profile Schema (Individual & Contact Points) & Resolution Troubleshooting
10 Chapter 10: Segment Architecture & Audience Design
10.1 Segmentation Canvas, Segment Types (Standard UI & Flow) & Query Processing 10.2 Direct vs. Related Attributes, Cardinality & 1:N Filtering Traps 10.3 Segment Schedule, Refresh Frequencies & Exclusion Logic 10.4 Segment Membership Analysis, Population Drift & Sizing Validation
11 Chapter 11: Calculated & Streaming Insights
11.1 Calculated Insights (CI) Architecture, SQL/Builder Syntax & Dimensions vs. Metrics 11.2 Streaming Insights (SI) Architecture, Windowing (Tumbling/Sliding) & Real-Time Signals 11.3 CI vs. SI Architectural Decision Matrix & Performance Optimization
12 Chapter 12: Data Enhancements, Sharing & Analysis
12.1 Referencing Data 360 Data from Other Systems: Enrichments, Related Lists, Data Graphs & APIs 12.2 Reports, Dashboards & Tableau Analysis on Data 360 Data 12.3 Applying Predictive & Generative AI Tooling to Customer Scenarios
13 Chapter 13: Activation Targets & Outbound Activation
13.1 Activation Targets: Marketing Cloud, External Platforms, Cloud Storage & Data Spaces 13.2 Activation Configuration: Audience Mapping, Related Attributes & Payload Optimization 13.3 Activation Schedules, Publishing Cadence & Incremental vs. Full Refresh 13.4 Activation Troubleshooting: Error Logs, Rejection Reasons & Delivery Failures
14 Chapter 14: Real-Time Data Actions & Flow Automation
14.1 Data Action Targets & Webhook/Platform Event Architecture 14.2 Data Cloud-Triggered Flows & Real-Time Business Orchestration 14.3 End-to-End Enterprise Scenario Walkthrough: Ingestion to Closed-Loop Action
3.2 Data Spaces Architecture, Resource Allocation & Tenant Isolation
Key Takeaways Explain This Topic AI
Data Spaces provide logical multi-tenant partitioning within a single Data Cloud instance, isolating data, metadata, and user operations across brands, regions, or business units.
Every Data Cloud instance includes a Default Data Space; custom Data Spaces ingest dedicated streams or consume shared Data Model Objects (DMOs) filtered by row-level criteria.
Identity Resolution rulesets belong strictly to individual Data Spaces, meaning profile unification and graph consolidation execute independently within each Data Space boundary.
Calculated Insights and Segments are strictly scoped to the Data Space where they are authored and cannot query data across Data Space boundaries.
Compute credits, streaming ingestion credits, and storage capacity are metered and pooled at the tenant level, requiring centralized governance even when operations are segregated across Data Spaces.
Last updated: September 2026
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:
Component Scoping Behavior Sharing Capability across Data Spaces
Data Streams Associated with a specific Data Space upon creation Dedicated to originating space; raw streams are not multi-cast
Data Lake Objects (DLOs) Bound to the parent Data Stream Scoped to stream's Data Space
Data Model Objects (DMOs) Canonical entities in Default or custom space Can be shared to multiple Data Spaces with optional Data Space Filters
Identity Resolution Rulesets Strictly isolated per Data Space Cannot span Data Spaces; rulesets execute only within local space
Calculated Insights (CIs) Scoped to authoring Data Space Executes only against data rows accessible within the local space
- Segments Scoped to authoring Data Space Can only query DMOs and CIs mapped to the local space
- Activation Targets Provisioned globally or per space Can be mapped to multiple Data Spaces by an Admin
- Activations Scoped to segment's Data Space Can only publish to Activation Targets assigned to that space
- User Access & The Data Space Switcher
User access to Data Spaces is administered through standard Salesforce Permission Sets combined with Data Space assignments:
Data Space Assignment : Administrators assign users to one or more Data Spaces based on their job responsibilities.
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.
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.
Evaluation Criteria Single-Org with Data Spaces Multi-Org (Separate Data Cloud Tenants)
Data Residency & Sovereignty Single physical Hyperforce region. Cannot satisfy strict physical multi-region residency mandates. Independent physical Hyperforce regions (e.g., one tenant in Germany, one in the US).
Cross-Brand Analytics Enabled by running Calculated Insights and Identity Resolution in the Default Data Space. Difficult; requires cross-instance data replication or external data lake federation.
Identity Resolution Rulesets isolated per space; optional central unification in Default space. Completely isolated identity graphs with zero native interoperability.
Connector & Ingestion Overhead Ingest once into Default space; filter and distribute across Data Spaces. Redundant connectors, pipelines, and schema mappings across every org.
Billing & Licensing Single contract, shared credit pool, shared platform license fees. Separate contracts, separate minimum credit commitments, higher total cost.
Administrative Overhead Centralized metadata management, shared canonical model, unified user administration. Multiplied administrative effort; decentralized change management.
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.