Salesforce Data Cloud DLO vs DMO — Complete Guide 2026 | Module 04
DLO vs DMO Deep Dive
Complete Guide 2026
Master Data Lake Objects and Data Model Objects — the most tested topic in every Data Cloud interview and the foundation of every successful implementation
- Data Lake Object — Complete Deep Dive
- Data Model Object — Complete Deep Dive
- DLO vs DMO — The Complete Comparison
- The Salesforce Canonical Data Model
- Every Standard DMO Explained
- DLO to DMO Mapping — Step by Step
- Critical Fields — Primary Key and Individual ID
- When and How to Create Custom DMOs
- Real-World Mapping Examples
- Common DLO and DMO Mistakes
- Quick Quiz
- Interview Questions for This Module
A Data Lake Object (DLO) is the raw data staging area that Data Cloud automatically creates when a Data Stream runs for the first time. It is the first landing point for all data entering Data Cloud — and it holds that data exactly as it arrived from the source system, with no modification whatsoever.
The DLO schema perfectly mirrors the source. If your Salesforce CRM Contact object sends data with a field called MobilePhone, the DLO will have a field called MobilePhone. If your marketing platform sends a field called email_address, the DLO has email_address. The DLO preserves source field names, data types and even the source system's quirks — including inconsistencies, null values and formatting differences.
This is intentional. The DLO captures a faithful, unmodified snapshot of the source data. Any cleaning, standardization or transformation happens downstream in the harmonization layer — never in the DLO itself.
| DLO Property | Value | Why It Matters |
|---|---|---|
| Created by | Automatically by Data Cloud on first Data Stream run | No manual creation needed — it just appears |
| Schema source | Mirrors source system exactly | Every source has its own DLO schema |
| Editable? | No — read-only staging area | Cannot change field names or data in DLO |
| Used for segmentation? | No — DLOs are invisible to segments | Must map to DMO before data is usable |
| Deduplication | Primary Key based — newest record wins | Same record arriving twice = upsert |
| Data quality | Raw — includes errors, nulls, inconsistencies | Cleaning happens in Data Transforms |
| One DLO per | Each Data Stream creates its own DLO | 10 Data Streams = 10 DLOs |
| Retention | Configurable — 90 to 365 days typically | Older data auto-archived to save credits |
DLO is Like the Inbox of Your Email
When an email arrives in your inbox it lands exactly as the sender wrote it — even if it has typos, unusual formatting or is in a different language. Your inbox does not automatically fix spelling errors or translate the content. It just stores what arrived.
That is exactly what a DLO does. Data arrives from the source exactly as it was sent — with all its flaws, inconsistencies and source-system quirks. The DLO just holds it faithfully.
Just as you need to process an email — read it, categorize it, respond to it — you need to process DLO data by mapping it to a DMO before it becomes useful for segmentation and insights.
A Data Model Object (DMO) is the standardized, harmonized version of your customer data — mapped to Salesforce's canonical data model. Where the DLO mirrors your source system, the DMO speaks Salesforce's universal language. Every DMO follows the same standard schema regardless of which source the data originally came from.
The DMO is where your data becomes truly useful. Segments filter on DMO fields. Calculated Insights query DMO data via SQL. Identity Resolution matches records from DMOs to build Unified Profiles. Activation reads profile attributes from DMOs. The DMO is the foundation of everything that makes Data Cloud powerful.
Salesforce provides a library of Standard DMOs — pre-built objects with standard field names that cover the most common customer data types. You map your DLO fields to these standard DMOs. When a standard DMO does not fit your business needs, you can create a Custom DMO with your own field definitions.
Data from your CRM calls the email field Email. Your marketing platform calls it email_address. Your website calls it user_email. After mapping all three to the Contact Point Email DMO, they all have the same field name. Identity Resolution can now match records across these three sources on the same field. Without DMOs this cross-source matching would be impossible.
📥 Data Lake Object (DLO)
- Raw data exactly as received from source
- Schema mirrors source system field names
- Auto-created by Data Cloud — no manual setup
- Read-only — cannot be edited or modified
- Cannot be used directly in segments or insights
- One DLO per Data Stream
- Intermediate staging layer — temporary home for data
- Data quality may be poor — nulls, inconsistencies
- Field names come from source: MobilePhone, email_address
- Exists even if no mapping has been done yet
🔧 Data Model Object (DMO)
- Harmonized, standardized data in canonical schema
- Schema follows Salesforce standard field names
- Configured manually via field mapping from DLO
- Can be queried via SQL for Calculated Insights
- Used directly in segments, insights and activation
- Multiple DLOs can map to the same DMO
- Permanent home for customer data in Data Cloud
- Data quality improved via Data Transforms before mapping
- Field names are standard: ContactPointEmail, Individual
- Only exists after field mapping is configured and run
The Canonical Data Model is Salesforce's pre-defined schema for organizing customer data in Data Cloud. It provides a library of standard DMOs with standard field names that represent the most common types of customer data across any industry.
The power of the canonical model is in its standardization. When you map a CRM Contact to the Individual DMO and a Marketing Cloud subscriber also to the Individual DMO — they now share the same field names. Identity Resolution can compare fields across both sources. Calculated Insights can aggregate across both. Segments can filter across both. Without a canonical model each source would remain siloed even after ingestion.
The canonical model is organized into Subject Areas — logical groupings of related DMOs. The Individual Subject Area contains all person-related objects. The Sales Order Subject Area contains all purchase-related objects. The Web and Mobile Subject Area contains behavioral event objects.
| Subject Area | Standard DMOs Included | Common Use |
|---|---|---|
| Individual | Individual, Unified Individual, Contact Point Email, Contact Point Phone, Contact Point Address, Contact Point Consent | Core customer identity and contact information |
| Sales Orders | Sales Order, Sales Order Product, Product, Product Category | Purchase history, transaction data, product catalog |
| Web and Mobile | Web Cart, Web Cart Product, Web Page View, Mobile App Event | Website and app behavioral events |
| Email Engagement | Email Engagement, Email Bounce, Email Send | Marketing email interaction tracking |
| Cases and Support | Case, Case Comment | Customer service history and interactions |
| Campaign | Campaign Member, Campaign, Marketing List Member | Marketing campaign participation and response |
| Loyalty | Loyalty Program Member, Loyalty Ledger | Loyalty points, tiers and redemption history |
Navigate to Data Streams and select your stream
In Data Cloud Setup, go to Data Streams. Find the Data Stream whose DLO you want to map. Click on it to open the stream settings. You will see the auto-generated DLO schema showing all the fields that arrived from the source.
Click Field Mapping
Inside the Data Stream settings, find the Field Mapping tab. This is where you connect DLO fields to DMO fields. Click New Mapping if no mapping exists yet, or edit an existing mapping to add or modify field connections.
Select the target DMO
Choose which DMO this DLO data should map to. For CRM Contact data, you would typically map to the Individual DMO and also to the Contact Point Email DMO and Contact Point Phone DMO. One DLO can map to multiple DMOs if the source object contains multiple types of data.
Map DLO fields to DMO fields
For each DMO field, select the corresponding DLO source field. For example, the DMO field First Name might map to the DLO field FirstName from CRM. The DMO field Email Address maps to the DLO field Email. Data Cloud provides suggestions based on field name similarity but you must verify each mapping is correct.
Set the Primary Key field
Every DMO mapping requires a Primary Key — the field that uniquely identifies each record within this DMO. For CRM Contact data this is typically the Salesforce Record ID. For Marketing Cloud subscriber data it is the Subscriber Key. If two records arrive with the same Primary Key, the newer record replaces the older one.
Map the Individual ID field — CRITICAL
The Individual ID field is what links each DMO record to a Unified Customer Profile. This is the most important field in the entire mapping. For CRM data, the Individual ID is typically the Contact ID or a custom field that identifies which customer this record belongs to. Without Individual ID mapped, the DMO data is completely orphaned and cannot be used in segmentation.
Set the Event Time field for engagement data
For engagement DMOs like Email Engagement, Web Cart and Mobile App events, you must map a timestamp field to the Event Time field in the DMO. This field tells Data Cloud when the event occurred and is required for time-based filtering in segments — such as customers who opened an email in the last 30 days.
Save mapping and trigger DMO refresh
Save the field mapping configuration. Data Cloud will automatically run a DMO refresh to populate the DMO with existing DLO data. Check the DMO data in Data Cloud Explorer to verify records are appearing correctly. Then run Identity Resolution to link new DMO records to Unified Profiles.
Individual ID is the most important field in any DLO to DMO mapping. Without it, records land in the DMO but are completely invisible to segments, Calculated Insights and Identity Resolution. Every mapping must have Individual ID configured. This is the single most common mistake in real Data Cloud implementations and the most common question in interviews.
| Field | Primary Key | Individual ID |
|---|---|---|
| What it does | Uniquely identifies each record within the DMO | Links each DMO record to a Unified Customer Profile |
| Used for | Deduplication — same key = upsert, newer wins | Identity Resolution — connects data to the right customer |
| Required? | Yes — every DMO mapping must have a Primary Key | Yes — for profile and engagement data |
| CRM Contact example | Salesforce Record ID (18-character ID) | Contact ID linking to the customer record |
| Marketing Cloud example | Subscriber Key | Contact Key linking to CRM Contact |
| What happens without it | Duplicate records overwrite incorrectly or create duplicates | Records in DMO but orphaned — invisible to segments |
| Data type | Must be unique string or number per record | Must match the Individual ID format used across all DMOs |
The Individual ID must be consistent across all DMOs for the same customer. If CRM uses Contact ID 001XX000001 as the Individual ID and Marketing Cloud uses a completely different Subscriber Key — Identity Resolution cannot link them. This is why establishing a common customer identifier across source systems is one of the first architectural decisions in every Data Cloud project.
When Do You Need a Custom DMO?
Standard DMOs cover the most common customer data types. But every business has unique data that does not fit neatly into a standard schema. A SaaS company has subscription data with billing cycles, seat counts and feature flags. An automotive company has vehicle ownership records. A healthcare company has appointment and treatment records. None of these have corresponding standard DMOs.
You create a Custom DMO when:
- No standard DMO exists for your data type
- A standard DMO exists but lacks required fields for your business
- You need to combine data from multiple sources into a unified business-specific object
- Your industry has specialized data — insurance policies, vehicle records, clinical trials
How to Create a Custom DMO
- Step 1: Navigate to Data Cloud Setup → Data Model → Data Model Objects → New
- Step 2: Define the DMO name and API name following your naming convention
- Step 3: Select the DMO Category — Profile or Engagement
- Step 4: Add fields — define field names, data types (Text, Number, Date, Boolean) and whether they are required
- Step 5: Mark one field as Primary Key
- Step 6: Add the Individual ID relationship field linking this DMO to Unified Individual
- Step 7: Save the custom DMO
- Step 8: Create a DLO to DMO field mapping pointing your Data Stream DLO to this custom DMO
Before creating a Custom DMO, always check the full Salesforce canonical model library to confirm no standard DMO fits. Custom DMOs require more maintenance when Salesforce releases updates to the canonical model. Standard DMOs receive automatic updates. When in doubt — extend a standard DMO with custom fields rather than creating a completely new custom DMO.
⚡ Salesforce CRM Contact → Multiple DMOs
One CRM Contact DLO maps to three separate DMOs simultaneously. Contact core fields (FirstName, LastName, Birthdate, Title) map to the Individual DMO. The Email field maps to Contact Point Email DMO with the contact's Salesforce ID as the Individual ID. The Phone and MobilePhone fields map to Contact Point Phone DMO. The MailingCity, MailingState and MailingCountry fields map to Contact Point Address DMO. One DLO, four mappings, four DMOs populated from the same source record.
📧 Marketing Cloud Subscriber → Individual + Contact Point Email
Marketing Cloud sends SubscriberKey, EmailAddress, FirstName, LastName and Status. EmailAddress maps to Contact Point Email DMO. SubscriberKey is the Primary Key and also the Individual ID — but only if CRM and Marketing Cloud share the same key format. If not, a separate match rule in Identity Resolution handles the cross-system linking. Status (Active, Unsubscribed) maps to a custom field in the Individual DMO to track subscription status.
🛒 E-Commerce Order History → Sales Order DMO
The order system sends order_id, customer_id, order_date, total_amount, currency_code and status. order_id is the Primary Key. customer_id maps to Individual ID — linking each order to the customer's Unified Profile. order_date maps to the OrderedDate field in Sales Order DMO. total_amount maps to GrandTotalAmount. Each line item in the order is a separate record mapping to the Sales Order Product DMO with a relationship back to the Sales Order via order_id.
🌐 Website Behavioral Events → Web Cart DMO
The web SDK sends event_type (add_to_cart, remove_from_cart), session_id, customer_id, product_id, product_price and event_timestamp. event_type and session_id combined form the Primary Key. customer_id is the Individual ID. product_id maps to the Product field in Web Cart DMO. event_timestamp maps to the Event Time field — critical for enabling time-based segment filters like customers who abandoned cart in the last 2 hours. This enables the real-time abandoned cart trigger via Data Actions.
Mistake 1: Forgetting to map Individual ID
The single most common mistake. Data flows beautifully into the DLO. Mapping looks correct. DMO shows records. But segments return zero results and Identity Resolution cannot match profiles. The root cause is always Individual ID not mapped. Every DMO mapping for profile and engagement data must have Individual ID configured. Make it the first field you check in any troubleshooting scenario.
Mistake 2: Using a non-unique field as the Primary Key
Setting the Primary Key to a field that is not truly unique — like customer city, product category or order status. When two records have the same Primary Key, the newer one replaces the older one. Using a non-unique Primary Key causes legitimate records to silently overwrite each other. Always use the source system's genuine unique identifier — Salesforce ID, database primary key or UUID.
Mistake 3: Mapping one DLO to one DMO only
A CRM Contact contains person identity data AND contact point data AND potentially address data. Mapping it only to the Individual DMO means email and phone data never reaches Contact Point Email and Contact Point Phone DMOs. Identity Resolution then has no email or phone to match on. Always analyze the source object fully and create mappings to every relevant DMO the data should populate.
Mistake 4: Not mapping the Event Time field for engagement data
Engagement DMOs like Email Engagement and Web Cart require a timestamp field mapped to Event Time. Without it, segment filters using time-based criteria — emails opened in last 30 days, cart abandoned in last 2 hours — cannot function. The data exists but all time-based segments return zero results because Data Cloud does not know when the event occurred.
Mistake 5: Creating custom DMOs when standard DMOs would work
Teams unfamiliar with the canonical model create custom DMOs for data that standard DMOs handle perfectly. A custom Product DMO when the standard Product DMO exists. A custom Email DMO when Contact Point Email exists. Custom DMOs require more ongoing maintenance, miss automatic Salesforce updates and create unnecessary complexity. Always check the full standard DMO library before creating custom objects.
Q1: B — DLO not mapped to DMO and Individual ID not set | Q2: C — Four DMOs | Q3: B — Unique identifier for deduplication | Q4: B — Event Time field not mapped | Q5: C — Individual ID
A Data Lake Object is the raw staging area automatically created when a Data Stream runs. It holds data exactly as received from the source system — same field names, same data types, same inconsistencies. A DLO is read-only and cannot be used for segmentation, Calculated Insights or activation. It is the intermediate landing zone for incoming data. A Data Model Object is the harmonized, standardized version of that data mapped to Salesforce's canonical schema. After mapping DLO fields to a DMO, the data follows consistent field names regardless of source and becomes available for segments, insights, Identity Resolution and activation. The key difference is that DLO is raw and source-specific while DMO is clean and standardized. You cannot skip the DMO — all Data Cloud features work exclusively on DMO data.
I would diagnose this in a sequential order. First I verify the Data Stream is actually delivering data by checking the DLO — if the DLO is empty, it is an ingestion problem not a mapping problem. If the DLO has data I move to field mapping — checking whether the DLO has been mapped to a DMO at all. If no mapping exists the data is completely invisible to segments. If mapping exists I check the two most critical fields — Primary Key and Individual ID. Without Individual ID mapped, DMO records cannot connect to Unified Profiles making them invisible to segmentation. Next I verify the DMO refresh has run after the mapping was saved. Then I check whether Identity Resolution has run and successfully linked profiles. Finally I review the segment filter criteria themselves to confirm they are actually matching the data values present in the DMO.
Individual ID is the connective tissue that links every DMO record to its Unified Customer Profile. Think of the Unified Profile as the master customer record and the Individual ID as the key that unlocks it. When a Sales Order DMO record has Individual ID mapped, Data Cloud knows which customer made that purchase and can show it on their Unified Profile. When a Web Cart DMO event has Individual ID mapped, Data Cloud knows which customer abandoned that cart. Without Individual ID, data lands in the DMO perfectly but is completely orphaned — it exists in isolation with no connection to any customer profile. It cannot be used in segments, it does not contribute to Calculated Insights and Identity Resolution cannot match it to any profile. Every single DMO mapping for profile and engagement data must have Individual ID configured or the entire ingestion effort produces zero usable output.
I create a custom DMO when no standard DMO exists that can represent the business-specific data I need to ingest. Before creating any custom DMO I always audit the full Salesforce canonical model library to confirm there is no suitable standard option. Common scenarios where custom DMOs are necessary include SaaS subscription data with billing cycles, seat counts and feature entitlements that have no standard equivalent. Automotive dealerships with vehicle ownership and service history records. Healthcare organizations with appointment, prescription and clinical trial data. Insurance companies with policy and claims records. The key principle is to prefer extending standard DMOs with custom fields when the core object fits but additional fields are needed — rather than creating a completely new custom DMO from scratch. Custom DMOs require more ongoing maintenance and do not receive automatic Salesforce canonical model updates.
A Salesforce CRM Contact object contains multiple types of data in one record — person identity attributes, email addresses, phone numbers and physical addresses. The Salesforce canonical model treats each of these as separate DMOs because they represent fundamentally different data types with different cardinalities. A customer can have multiple email addresses stored in Contact Point Email DMO — personal and work. A customer can have multiple phone numbers in Contact Point Phone DMO. If all this data was forced into a single Individual DMO you would lose the ability to store multiple contact points per customer. By mapping the single Contact DLO to Individual DMO for name and demographics, Contact Point Email DMO for email, Contact Point Phone DMO for phone and Contact Point Address DMO for address — you correctly represent the one-to-many relationships and enable Identity Resolution to match on email and phone fields specifically.