Salesforce Data 360 Data Model: DSO vs DLO vs DMO, Normalization & Cardinality Explained

💬 In plain words: Salesforce Data 360 processes data through a three-stage pipeline:

• Data Source Object (DSO): The raw landing zone auto-created when a stream connects.
• Data Lake Object (DLO): Stored, structured, and normalized data within the lake.
• Data Model Object (DMO): The canonical, standardized business object used for segmentation, insights, and activation.

Mapping always flows upward: DLO → DMO. Configure your relationship cardinality accurately (for example, one customer to many purchases), or your identity resolution rules will break.

⚡ 1-Minute Summary

• The Object Progression: Source Data → DSO (raw stream representation) → DLO (normalized storage) → DMO (canonical consumption model).
• Normalization vs. Denormalization: Normalize early at the DLO layer for data integrity and storage efficiency; denormalize late at the DMO layer for rapid query performance.
• Downstream Rule: Calculated Insights, audience segments, and Agentforce grounding read exclusively from mapped DMOs, never directly from raw DLOs or DSOs.

📌 Real-World Architecture Example:

A point-of-sale (POS) terminal sends a transaction payload: { "txn_id": "TXN-88", "cust_num": "C-1023", "amount": 4500 }.

• Ingest (DSO): Raw stream captures the payload verbatim without modification.
• Store (DLO): Data is typed, cleaned, and stored in the normalized POS_Transactions_DLO table.
• Harmonize (DMO): The DLO maps to the standard SalesOrder DMO, joined via foreign key to the Individual DMO with a 1:N (one-to-many) relationship.

The Three-Stage Data Progression: DSO → DLO → DMO

Salesforce Data 360 relies on a deliberate object lifecycle to separate raw ingestion from analytical consumption:

• 1. Data Source Object (DSO): Automatically generated when setting up a Data Stream. It acts as the raw schema contract representing incoming records from external sources.
• 2. Data Lake Object (DLO): Physical tables in the underlying lake storage. Ingested records flow from the DSO into the DLO, where data types are enforced and storage is organized into a normalized structure.
• 3. Data Model Object (DMO): The unified, canonical layer built upon the standard Cloud Information Model (CIM). Administrators map fields from DLOs into DMOs during the Harmonization phase.
• Golden Rule of Mapping: Field mapping is unidirectional—always from DLO → DMO. Downstream tools like Segment Canvas, Calculated Insights, and activation targets consume only DMOs.

DATA OBJECT PROGRESSION PIPELINE
Source Payload ──► DSO (Raw stream contract created at ingestion)
                   └──► DLO (Normalized lake object for storage integrity)
                        └──► [Harmonization Mapping]
                             └──► DMO (Canonical business model for queries)

ARCHITECTURAL PRINCIPLE:
- Normalize at DLO  ──► Eliminates duplicate records, ensures storage integrity
- Denormalize at DMO ─► Flattens attributes, maximizes real-time read speed

Normalization vs. Denormalization & Key Relationships

Enterprise data modeling balances data integrity against query performance by leveraging two complementary structural models:

• Normalized Layer (DLO): Divides data across discrete, specialized relational tables. This eliminates storage redundancy, safeguards transactional integrity, and scales write workloads efficiently.
• Denormalized Layer (DMO): Consolidates related fields and attributes into broader, unified tables. This minimizes expensive relational joins during real-time audience queries and calculated metrics.
• Primary Keys (PK): Uniquely identify individual rows within a DLO or DMO. If an external system lacks a natural primary key, Data 360 can generate one using composite field formulas (e.g., SourceSystem + "_" + CustomerId + "_" + Email) or auto-generated keys during stream setup.
• Foreign Keys (FK) & Cardinality: Child tables reference parent primary keys. You must establish explicit relationship cardinalities (1:1, 1:N, or N:N) to enable the identity engine and query graph to traverse related tables accurately.
• Standard vs. Custom DMOs: Always map to standard Salesforce DMOs (such as Individual, ContactPointEmail, ContactPointPhone, or Account) first. Extend standard DMOs with custom fields when necessary, reserving custom DMOs for distinct business domain entities.

🧠 Object Pipeline Mnemonic: 'DSO → DLO → DMO'. DSO receives the raw feed, DLO provides normalized storage, and DMO provides the query-ready canonical model. Always map low (DLO) to high (DMO).

⚠️ Cardinality Trap: If you misconfigure relationship cardinality—such as defining an Order-to-Customer relationship as 1:1 instead of 1:N—Identity Resolution will overwrite existing transaction data and corrupt audience segmentation queries.

🧭 360 Card: DSO, DLO, & DMO Architecture

• Core Rule: Raw data streams create DSOs, persist into DLOs, and map up to standard DMOs. Downstream segmentation reads only DMOs.
• Key Architectural Gain: A predictable data pipeline ensures that troubleshooting missing fields always follows the same three verification checkpoints: DSO stream status, DLO persistence, and DMO field mapping.
• Schema Complexity: Ingestion requires defining data types and primary key structures across three layers before data is actionable.
• Field Consistency: Field data types must match precisely between the DLO source field and the target DMO destination attribute (e.g., Text to Text, Number to Number).
• Direct Source Anti-Pattern: Bypassing the canonical model to point analytics directly at source schemas creates tight coupling and requires rebuilding downstream queries for every new ingestion channel.

Technical Deep Dive: Questions & Architecture Scenarios

Q: Walk through what happens to data structurally from the moment a data stream lands until a segment can query it.

🎯 Core Rule: Incoming data lands in a DSO, persists into a normalized DLO, and is mapped to a canonical DMO. Audience segments query only DMOs.

Step-by-Step Architectural Flow:

• 1. Ingestion via DSO: Creating a Data Stream instantiates a Data Source Object (DSO) that mirrors the schema of the source connection.
• 2. Storage in DLO: Records transition from the DSO into physical Data Lake Objects (DLOs), structuring data for normalized lake storage.
• 3. Harmonization via DMO Mapping: Administrators map DLO fields into canonical Data Model Objects (DMOs) like Individual or SalesOrder, establishing primary and foreign key relationships.
• 4. Downstream Activation: Audience Segment builders, Calculated Insights, and Agentforce actions execute their query plans against the denormalized DMO layer.

Scenario 1: A legacy source feed contains no unique primary key. How does Data 360 resolve keys and establish relationships?

Solution Architecture:

• Formula Key Construction: Use ingestion transform formulas to concatenate stable source fields (such as SourceSystem + "_" + AccountId + "_" + Email) into a deterministic unique identifier.
• Auto-Generated Keys: Enable Data 360's built-in key generation during stream setup to produce unique surrogate IDs automatically.
• Foreign Key Binding: Map the generated surrogate key as the primary key on the parent DMO and reference it from related child DMO foreign key fields.
• Data Integrity Impact: Correctly defined composite keys prevent profile splitting and eliminate accidental record overwrites during identity resolution.

Scenario 2: Why are DLOs designed to be normalized while DMOs are typically denormalized?

Architectural Rationale:

• DLO Normalization for Write Performance: DLOs handle high-volume write operations across streaming and batch ingestion. Normalizing tables eliminates data redundancy, guarantees transactional consistency, and reduces storage overhead.
• DMO Denormalization for Query Performance: DMOs serve real-time analytical workloads, audience queries, and conversational AI lookups. Denormalizing attributes into broader objects minimizes complex multi-table SQL joins, delivering sub-second response times.