Salesforce Data Cloud Architecture — Complete Guide 2026 | Module 02
Salesforce Data Cloud Architecture
Complete Guide 2026
Deep dive into every layer of the Data Cloud architecture — from data ingestion to activation — with real diagrams, examples and interview questions
- Data Cloud Architecture Overview
- The 5 Architecture Layers Explained in Depth
- Data Sources — What Can Connect to Data Cloud
- How Data Cloud Connects to Every Salesforce Cloud
- Hyperforce — The Infrastructure Behind Data Cloud
- Traditional CDP vs Data Cloud Architecture
- Real-World Architecture Examples
- Common Architecture Mistakes
- Quick Quiz
- Interview Questions for This Module
Salesforce Data Cloud is not just a database. It is a layered architectural platform that moves customer data through five distinct stages — each stage transforming raw data into actionable intelligence.
Understanding the architecture is critical because every Data Cloud feature, concept and implementation decision maps back to one of these layers. When something goes wrong in Data Cloud — and it will — knowing the architecture tells you exactly where to look.
The architecture is designed around one core principle: data should flow in one direction — from raw source to intelligent action. Every layer has a specific job, specific objects and specific tools.
In Data Cloud, data always flows forward through the architecture — Source → DLO → DMO → Unified Profile → Segment → Activation. You cannot skip layers. Each layer depends on the one before it being correctly configured.
Layer 1 — Ingestion in Detail
The Ingestion layer is the entry point for all data into Data Cloud. No data can exist in Data Cloud without passing through this layer. It uses two primary mechanisms — Connectors and Data Streams.
A Connector is the integration technology that establishes a connection to a source system. Think of it as the pipe itself. A Data Stream is the specific configured flow of data through that pipe — defining which object, which fields and how often data flows.
One Connector can power multiple Data Streams. For example — one Salesforce CRM Connector can have separate Data Streams for Account, Contact, Opportunity and Case objects.
Ingestion supports two modes. Batch ingestion collects data on a scheduled interval — hourly, daily or weekly. It is cost-efficient and suited for data that does not change rapidly. Streaming ingestion processes individual events as they happen in real-time — within seconds. It is more expensive in Data Credits but enables real-time personalization and triggers.
Layer 2 — Harmonization in Detail
When data arrives through a Data Stream it lands exactly as-is in a Data Lake Object (DLO). A DLO mirrors the source schema perfectly — if your CRM Contact object has a field called Account_Name__c, that is what the DLO field is called.
The problem is that every source has different field names, data types and structures. The email field from CRM is called Email. From Marketing Cloud it is EmailAddress. From the website it is user_email. They all mean the same thing but look completely different.
Harmonization solves this by mapping DLO fields to Data Model Objects (DMOs) — Salesforce's standardized canonical schema. After mapping, the email field from every source maps to Contact Point Email DMO — one consistent field name regardless of source.
Data Transforms add another layer here — allowing SQL-based cleaning and enrichment before data lands in the DMO. Normalizing phone formats, standardizing name casing, deriving new fields — all happen in this layer.
Layer 3 — Unification in Detail
After harmonization you may have the same customer appearing as multiple DMO records — one from CRM, one from Marketing Cloud, one from the website. The Unification layer uses Identity Resolution to merge these into one Unified Customer Profile.
Identity Resolution works in two stages. First, Match Rules determine which records belong to the same person — using deterministic matching (exact email match) or probabilistic matching (similar name + city + partial email). Second, Reconciliation Rules determine which value wins when two sources disagree on a field — Most Recent, Most Frequent or Source Priority.
The output of this layer is the Unified Individual DMO — one clean, deduplicated record per real-world customer, drawing the best data from every source.
Layer 4 — Insights and Segmentation in Detail
With clean unified profiles, this layer answers the question — what do we know about each customer and which customers should we target?
Calculated Insights use ANSI-compatible SQL to compute metrics like Customer Lifetime Value, churn probability, purchase frequency and product affinity. These metrics are computed on a schedule and stored directly on each Unified Customer Profile for instant retrieval.
Segments group Unified Profiles into audiences using a no-code filter builder — combining attribute filters, DMO relationship filters and Calculated Insight thresholds. Segments refresh on Full, Rapid or Real-time schedules depending on urgency.
Data Graphs — a newer addition — pre-map relationships between DMOs for Agentforce AI agents to retrieve complete customer context in a single structured call.
Layer 5 — Activation in Detail
Activation is where insights become action. This layer pushes segments and profile attributes to external systems that can act on them — sending emails, running ads, personalizing AI responses.
You configure an Activation Target once per destination system — Marketing Cloud, Facebook Ads, Google Ads, Amazon Ads, cloud storage or custom webhooks. Each Activation then maps segment membership and selected profile attributes to that target's field schema.
Data Actions in this layer enable real-time triggers — firing instantly when a customer profile condition is met, without waiting for a scheduled segment refresh. A customer's churn score crossing a threshold can immediately trigger a Flow, a Marketing Cloud journey or a webhook to an external system.
| Source Type | Connector | Ingestion Mode | Common Use Case |
|---|---|---|---|
| Salesforce CRM | Salesforce CRM Connector | Batch (scheduled) | Account, Contact, Case, Opportunity data |
| Marketing Cloud | Marketing Cloud Connector | Batch | Email opens, clicks, bounces, subscriber data |
| Cloud Storage | Amazon S3, Google Cloud, Azure Blob | Batch | CSV exports from ERP, historical data |
| Mobile & Web | Salesforce CDP Mobile SDK, Web SDK | Streaming | App events, page views, clickstream |
| Custom API | Ingestion API (REST) | Streaming or Bulk | Any custom system, IoT devices, third-party apps |
| MuleSoft | MuleSoft Connector | Batch or Streaming | ERP, SAP, third-party CRM, legacy systems |
| Snowflake | Zero Copy (Secure Share) | Real-time query | Data warehouse tables without duplication |
| Google BigQuery | Zero Copy | Real-time query | Analytics warehouse data |
| Amazon Redshift | Zero Copy | Real-time query | AWS-hosted data warehouse |
| Commerce Cloud | Commerce Cloud Connector | Batch | Order history, cart events, product catalog |
Not all data needs to come INTO Data Cloud. Zero Copy allows Data Cloud to read data from Snowflake, BigQuery and Redshift in place — without ingesting it. This is the most cost-efficient approach for large volumes of data that already live in a data warehouse.
Think of Data Cloud as a City's Central Power Grid
Each Salesforce cloud — Sales Cloud, Service Cloud, Marketing Cloud — is like a building in a city. Each building can operate on its own small generator — that is like using Einstein features in isolation within each cloud.
Data Cloud is like connecting all those buildings to a central power grid. Every building gets the same consistent power source — unified customer data — instead of each running on its own disconnected generator. The power is stronger, more consistent and shared across everything.
When you turn on Agentforce — it draws power from the same grid. When Marketing Cloud runs a campaign — same grid. When a Service agent opens a case — same grid. One unified source powering everything.
What is Hyperforce?
Hyperforce is Salesforce's next-generation cloud infrastructure built on major public cloud providers — Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform. Data Cloud runs on Hyperforce which gives it elastic scalability, regional data residency and enterprise-grade security.
Before Hyperforce, Salesforce ran on its own proprietary data centers. Hyperforce moves Salesforce infrastructure to public cloud providers while maintaining Salesforce's multi-tenant architecture and security model.
| Hyperforce Benefit | What It Means for Data Cloud | Why It Matters |
|---|---|---|
| Regional Data Residency | Data Cloud data stored in specific country or region | GDPR compliance — EU data stays in EU |
| Data Sovereignty | Government and financial customers data within national borders | Regulatory compliance for regulated industries |
| Elastic Scale | Public cloud compute scales to handle billions of events | 50M+ customer profiles processed without performance issues |
| Security Certifications | ISO 27001, SOC2, FedRAMP, HIPAA compliance | Enterprise and government customers can use Data Cloud |
| Performance | Data Cloud compute co-located with customer data | Lower latency for real-time streaming and activation |
| Provider Choice | Customers can choose AWS, Azure or GCP region | Matches existing cloud provider strategy |
Hyperforce is not just a technical topic — it is a business enabler. When an interviewer asks why a healthcare company or government agency can use Data Cloud, the answer involves Hyperforce providing HIPAA compliance, FedRAMP authorization and regional data residency. Always connect Hyperforce to compliance and sovereignty requirements.
| Architecture Factor | Traditional CDP | Salesforce Data Cloud |
|---|---|---|
| Processing Model | Batch-only — data updated daily or weekly | Real-time streaming + batch — seconds to daily |
| Identity Resolution | Basic rule-based matching, limited sources | AI-powered deterministic and probabilistic at scale |
| Data Volume | Millions of profiles | Billions of profiles and events |
| External Data | Must copy all data in — no alternative | Zero Copy — query Snowflake/BigQuery in place |
| AI Integration | Separate AI tools, no native connection | Native Agentforce and Einstein integration |
| Activation | Export files, manual process | Real-time native activation to any Salesforce cloud |
| Infrastructure | Fixed data center capacity | Hyperforce — elastic public cloud scale |
| Governance | Manual consent management | Contact Point Consent DMO — automated compliance |
🛒 Retail Company — Full Architecture
Sources: Salesforce CRM (Account, Contact), Commerce Cloud (Orders, Cart events via streaming), Marketing Cloud (Email engagement), Mobile App (behavioral events via Ingestion API), Loyalty System (points via S3 batch). Identity Resolution: Deterministic on email and phone, probabilistic fallback for anonymous users. Calculated Insights: LTV, purchase frequency, product affinity, days since last purchase. Segments: VIP Gold, Win-back 90 days, Abandoned Cart. Activation: Marketing Cloud for campaigns, Facebook for lookalike audiences, Agentforce for personalized service responses.
🏥 Financial Services — Compliant Architecture
Infrastructure: Hyperforce EU region for GDPR compliance. Data Spaces: Retail Banking vs Wealth Management separated. Sources: Core Banking System via MuleSoft, CRM, Mobile App via streaming, Call Center recordings metadata. Strict consent management via Contact Point Consent DMO. Calculated Insights: Churn risk score, product propensity, relationship profitability. Zero Copy from Snowflake for historical transaction analysis without moving data into Data Cloud.
🤝 B2B SaaS — Account-Based Architecture
Primary entity: Account (not Individual). Sources: Salesforce CRM, Product usage analytics via Ingestion API streaming, Support tickets, Billing system via S3. Calculated Insights: Account health score, feature adoption rate, days to renewal, NPS trend. Segments: At-risk accounts 60 days pre-renewal, high-expansion accounts, onboarding incomplete. Activation: Sales Cloud task creation via Data Action, Agentforce SDR agent for targeted outreach.
Mistake 1: Streaming everything
Teams default to streaming ingestion for all data because it feels more powerful. But streaming costs significantly more Data Credits than batch. Customer demographics from CRM change monthly — not every second. Only stream data that genuinely requires real-time processing — behavioral events, cart actions, live interactions.
Mistake 2: Ingesting every field from every source
The temptation is to bring in everything. The reality is that every field ingested costs credits to process and store. Before configuring any Data Stream, define exactly which fields are needed for segmentation, insights and activation. Only ingest those fields. Leave the rest in the source system.
Mistake 3: Skipping the data quality layer
Teams rush to configure Data Streams and field mapping without addressing data quality first. Dirty data entering Identity Resolution creates merged profiles of completely different people or fails to merge records that should be the same person. Always build Data Transforms for normalization before Identity Resolution runs.
Mistake 4: Not mapping Individual ID in every DLO
Individual ID is the field that links every DMO record to a Unified Customer Profile. If it is not mapped — the data lands in the DMO but never connects to any profile. It becomes invisible to segmentation, insights and activation. Every DLO must have Individual ID mapped — without exception.
Mistake 5: Building too many segments too early
Teams build 50 segments on day one before validating that the underlying data and Identity Resolution are correct. Each segment consumes credits on every refresh. Build 3 to 5 core segments first, validate the data quality, then expand. Incorrect segments with bad underlying data waste credits and produce wrong activations.
Always design Data Cloud architecture in this order — Data Quality first, then Identity Resolution, then Insights, then Segments, then Activation. Every layer depends on the quality of the layer before it. Getting the foundation right means every subsequent layer works correctly.
Q1: C — Identity Resolution | Q2: C — Zero Copy | Q3: B — Hyperforce regional data residency | Q4: D — Data Cloud | Q5: B — Streaming everything and ingesting every field
Data Cloud architecture follows five sequential layers. The first layer is Ingestion — data enters from source systems via Connectors and Data Streams, either as scheduled batch or real-time streaming. Raw data lands in Data Lake Objects exactly as received from the source. The second layer is Harmonization — DLO fields are mapped to standardized Data Model Objects following Salesforce's canonical schema, with Data Transforms cleaning and enriching data before it lands in DMOs. The third layer is Unification — Identity Resolution uses Match Rules to merge records from different sources belonging to the same customer into one Unified Individual. The fourth layer is Insights and Segmentation — Calculated Insights compute metrics like LTV and churn score via SQL, and Segments group Unified Profiles into audiences using filter criteria. The fifth layer is Activation — segments and profile attributes are pushed to Activation Targets like Marketing Cloud, advertising platforms or Agentforce for action.
For a client with data already in Snowflake, I would use Zero Copy architecture as the primary approach. Using Snowflake Secure Share, Data Cloud can access Snowflake tables directly without duplicating them into Data Cloud. This saves Data Credits, ensures data is always current without sync delays and maintains Snowflake's governance and security controls. I would configure Data Cloud to treat the shared Snowflake tables as native DLOs, map them to DMOs, run Identity Resolution and build segments — all while the raw data stays in Snowflake. For behavioral and real-time event data that is not in Snowflake, I would add streaming Data Streams via the Ingestion API. The hybrid approach uses Zero Copy for historical data and streaming ingestion for real-time events.
Data Cloud is the intelligence foundation for Agentforce. Without Data Cloud, Agentforce agents only have access to what is currently visible in a single Salesforce object. With Data Cloud, agents access the complete Unified Customer Profile — combining CRM history, purchase transactions, email engagement, support cases and behavioral data into one context. Data Graphs in Data Cloud pre-map relationships between DMOs so Agentforce can retrieve all related customer data in a single structured call rather than multiple separate queries. Calculated Insights like churn score and LTV stored on Unified Profiles allow Agentforce to make intelligent routing decisions — escalating high-value at-risk customers to human agents automatically. This is how RAG grounding works in practice — Agentforce retrieves real Data Cloud profile data before generating any AI response.
The choice between batch and streaming comes down to three factors — how frequently the data changes, how quickly you need to act on it, and the Data Credit cost. Streaming costs significantly more credits than batch per record processed. Customer demographic data like name, address and job title changes rarely — monthly at most. Streaming this data in real-time wastes credits with no business benefit. Batch ingestion on a daily schedule is perfectly sufficient. CRM Account and Contact objects, weekly ERP exports, monthly loyalty tier updates — all of these are ideal for batch. Streaming should be reserved for data where acting on it within seconds creates business value — cart abandonment events, real-time support interactions, live IoT sensor data, fraud signals. The rule I follow is — if the business outcome does not change by acting one hour later instead of one second later, use batch.
Regulated industries have strict requirements about where customer data is stored and who can access it. Hyperforce addresses this by running Data Cloud on public cloud infrastructure — AWS, Azure or Google Cloud — in specific geographic regions. A European bank can run Data Cloud on AWS Frankfurt ensuring no customer data leaves the European Union — satisfying GDPR requirements. A US healthcare company can run on AWS US-East with HIPAA compliance and FedRAMP authorization for government-adjacent data. Hyperforce also provides the security certifications these industries require — ISO 27001, SOC2 Type 2, HIPAA and FedRAMP. Beyond residency, Hyperforce's elastic compute allows Data Cloud to process billions of healthcare or financial records without dedicated infrastructure investment. The combination of regional residency, compliance certifications and elastic scale makes Data Cloud viable for industries that previously could not consider cloud-based CDPs.