Technical Architecture and Data Governance
Architecture
Data Cloud runs on Hyperforce with a storage/compute separation: ingested data lands in Data Cloud storage as DLOs, is harmonized into DMOs, and is queried by Data Cloud's own query engine. It is multi-tenant and scales independently of core Salesforce transaction limits, which is why large-volume analytics and segmentation belong here rather than in reports over CRM objects.
Governance controls
- Data spaces partition data, metadata, connections, and user access.
- Permission sets and object/field permissions govern what a Data Cloud user can do; core Salesforce sharing rules, roles, and org-wide defaults do not apply to Data Cloud objects.
- Data masking policies protect sensitive fields such as emails, phones, and national IDs while keeping data usable.
- Consent management governs activation eligibility for individuals.
- Credits and limits cover storage, compute, and profile/segment volumes; ingestion, insights, and activation all consume them.
- Audit and lineage through stream, mapping, and job history tells you where a field came from and when it last refreshed.
Traps
- Assuming core Salesforce sharing rules or field-level security carry over to Data Cloud.
- Assigning a user to the wrong data space and then debugging "missing data."
- Forgetting masking when the question asks how to protect PII in a sandbox.
- Ignoring credit consumption when designing high-frequency streaming ingestion and activation.
Rule of thumb
When access is wrong, check in this order: data space membership → permission set → object/field permission → masking policy. Most "I can't see the data" scenarios stop at step one.