7.2 DLO-to-DMO Mapping Patterns, Cardinality & Custom DMO Design

DLO-to-DMO Mapping Patterns, Cardinality & Custom DMO Design

Once raw source data has been ingested into physical Data Lake Objects (DLOs), the critical next step in the Data Cloud pipeline is data mapping. Through the Data Mapping Canvas, consultants translate source-specific physical schemas into the standardized semantic Customer 360 Data Model Objects (DMOs).

Mapping is not merely a cosmetic aliasing exercise: how source fields are mapped, how cardinality is configured, and how relationships are established between DMOs directly determines whether Identity Resolution can unify records, whether the Segment Builder can traverse behavioral attributes, and whether Calculated Insights can execute performant analytical aggregations.

---

The Data Mapping Canvas Architecture

The Data Mapping Canvas is Data Cloud's visual design environment for connecting DLO fields to DMO fields. When configuring mappings, consultants navigate between the source DLO on the left and the target canonical DMO on the right, drawing connections between attributes.

┌──────────────────────────────────────┐             ┌──────────────────────────────────────┐
│      SOURCE DATA LAKE OBJECT         │             │      TARGET DATA MODEL OBJECT        │
│         Contact_DLO__dll             │             │           Individual__dlm            │
├──────────────────────────────────────┤             ├──────────────────────────────────────┤
│  CRM_Contact_ID__c (Text)            ├────────────►│  Id__c (Text - Primary Key)          │
│  First_Name__c (Text)                ├────────────►│  FirstName__c (Text)                 │
│  Last_Name__c (Text)                 ├────────────►│  LastName__c (Text)                  │
│  Date_of_Birth__c (Date)             ├────────────►│  BirthDate__c (Date)                 │
│  Customer_Segment__c (Text)          ├────────────►│  CustomerSegment__c (Custom Field)   │
└──────────────────────────────────────┘             └──────────────────────────────────────┘

Mandatory Rules on the Mapping Canvas

1. Primary Key Mapping is Strictly Required: Every DMO has a designated Primary Key (Id__c). The mapping canvas will not allow deployment if the target DMO's primary key remains unmapped.
2. Strict Data Type Compatibility: The source DLO field and target DMO field must have compatible data types:
   • Text ➔ Text
   • Number ➔ Number
   • Date ➔ Date
   • DateTime ➔ DateTime
   • Attempting to map a Text field containing string timestamps into a DateTime DMO field will trigger a validation error. Data conversion must occur prior to mapping via Ingestion Formula Fields.
3. Custom Field Mapping on Standard DMOs: If the source DLO contains attributes that do not map to standard CIM fields, consultants can add Custom Fields directly to standard DMOs. Custom fields automatically append the __c suffix and behave identically to standard fields in segmentation and activation.

---

Mapping Cardinality Topologies

Depending on the schema architecture of the incoming source systems, consultants deploy one of three core mapping topologies: 1:1 Mapping, 1:Many Mapping, or Many:1 Mapping.

1. 1:1 Mapping Pattern

• Definition: A single source DLO maps directly to a single target DMO.
• Typical Use Cases: Ingesting a clean, normalized relational table where each row corresponds directly to a canonical entity.
  • Example: A Salesforce CRM Contact DLO mapping exclusively to Individual__dlm.
  • Example: An ERP Product Catalog DLO mapping exclusively to GoodsProduct__dlm.
• Key Architectural Rule: The primary key of the DLO is mapped directly to the primary key (Id__c) of the target DMO.

2. 1:Many Mapping Pattern (The Wide Table Deconstruction Pattern)

• Definition: A single source DLO maps to multiple distinct target DMOs.
• The Enterprise Challenge: Legacy marketing lists, point-of-sale customer tables, or external CRM exports frequently arrive as flat, "wide" records. A single customer row might contain: Customer_ID, First_Name, Last_Name, Personal_Email, Work_Email, Mobile_Phone, Work_Phone, Billing_Street, Billing_City, and Billing_Zip.
• The Harmonization Solution: Because the Customer 360 model normalizes contact channels into separate objects, this single DLO must be mapped multiple times:
  1. Map DLO ➔ Individual__dlm (Maps Name, BirthDate, Customer ID ➔ Id__c).
  2. Map DLO ➔ ContactPointEmail__dlm for Personal Email (Maps Personal Email ➔ EmailAddress__c).
  3. Map DLO ➔ ContactPointEmail__dlm for Work Email (Maps Work Email ➔ EmailAddress__c).
  4. Map DLO ➔ ContactPointPhone__dlm for Mobile Phone (Maps Mobile Phone ➔ TelephoneNumber__c).
  5. Map DLO ➔ ContactPointAddress__dlm for Billing Address.

[!CAUTION] The Composite Primary Key Mandate in 1:Many Mappings Every record in a DMO must have a unique Id__c. If a customer with Customer_ID = "C-101" has both a Personal Email and a Work Email, you CANNOT map Customer_ID as the primary key for both ContactPointEmail__dlm records! If you do, the second record will overwrite the first in lakehouse storage.

Consultant Solution: Create Ingestion Formula Fields on the Data Stream to generate unique composite primary keys for each contact point:

• Personal_Email_PK__c = CONCAT(source.Customer_ID, "_email_personal")
• Work_Email_PK__c = CONCAT(source.Customer_ID, "_email_work")
• Mobile_Phone_PK__c = CONCAT(source.Customer_ID, "_phone_mobile")

Map these composite formula fields to the respective Id__c fields of the Contact Point DMOs, while mapping the raw Customer_ID to PartyId__c on all of them to maintain relational linkage to the Individual!

3. Many:1 Mapping Pattern (Multi-Source Ingestion into Canonical DMO)

• Definition: Multiple disparate source DLOs map into the same target canonical DMO.
• Typical Use Cases: Enterprise multi-system customer consolidation.
  • Source 1: Service Cloud Contact_DLO maps to Individual__dlm.
  • Source 2: Sales Cloud Lead_DLO maps to Individual__dlm.
  • Source 3: Marketing Cloud Subscriber_DLO maps to Individual__dlm.
  • Source 4: E-Commerce Shopper_DLO maps to Individual__dlm.
• Key Architectural Rule: To prevent records from different source systems overwriting each other in the canonical DMO due to coincidentally matching IDs (e.g., both systems having an ID 001), each source DLO MUST prepend a unique source or tenant prefix to its primary key at ingestion (e.g., CONCAT("SVC_", Id) vs CONCAT("MKT_", SubscriberKey)).

Mapping Cardinality Topologies Comparison

---

Custom DMO Design & Governance

While the Customer 360 Data Model provides robust coverage across retail, sales, service, and marketing domains, specialized industries often require storing entities that have no representation in standard CIM subject areas.

When to Create a Custom DMO (CustomEntity__dlm)

• Approved Custom DMO Scenarios:
  • Healthcare & Life Sciences: Clinical Trial Protocols, Prescription Authorizations, Medical Devices.
  • Automotive & Manufacturing: Vehicle Telematics, Warranty Claims, Dealer Franchise Locations.
  • Travel & Hospitality: Flight Manifests, Cabin Upgrades, Hotel Room Reservations.
  • Financial Services: Insurance Underwriting Policies, Loan Applications, Wealth Portfolios.
• Anti-Pattern (When NOT to create a Custom DMO):
  • Do NOT create a custom DMO for customer profiles (use Individual__dlm).
  • Do NOT create a custom DMO for business accounts (use Account__dlm).
  • Do NOT create a custom DMO for transactions (use SalesOrder__dlm and SalesOrderProduct__dlm).
  • If standard DMOs simply lack 5 or 10 specific attributes, add custom fields to the standard DMO instead of building a custom object.

Architectural Steps for Custom DMO Creation

1. Select Creation Method: In Data Model management, create a new DMO from scratch or clone an existing template.
2. Configure Object Properties:
   • Label & API Name: Standard camel-case label; the system automatically appends the __dlm suffix.
   • Category Selection: Must select Profile, Engagement, or Other.
     • Profile: Persistent entities (e.g., Patient__dlm, InsuredParty__dlm).
     • Engagement: Behavioral time-stamped events (e.g., VehicleTelematicsPing__dlm, PrescriptionRefillEvent__dlm). Requires an Event Time field!
     • Other: Reference catalogs (e.g., WarrantyPlanLookup__dlm, DealerLocation__dlm).
3. Define the Primary Key: Explicitly designate a Text field as the Primary Key (Id__c).
4. Define Custom Relationships: Configure foreign key lookup relationships linking the custom DMO to other DMOs.

Standard DMO Extension vs. Custom DMO Decision Matrix

---

Relational Cardinality & Downstream Impact

In Data Cloud, configuring relationships between DMOs is not just for documentation—it builds the relational graph that powers the Segment Builder and Calculated Insights query engines.

┌───────────────────────┐            1:N            ┌───────────────────────┐
│    Individual__dlm    │──────────────────────────►│    SalesOrder__dlm    │
│  PK: Id__c            │◄──────────────────────────│  PK: Id__c            │
└───────────────────────┘            N:1            │  FK: SoldToPartyId__c │
                                                    └───────────────────────┘

Cardinality Definitions & Directions

When establishing a relationship in the Data Model canvas, the consultant defines:

1. Source DMO & Target DMO: Which object contains the Foreign Key and which contains the Primary Key.
2. Cardinality Type:
   • Many-to-One (N:1): Many records in the source object relate to one record in the target object (e.g., many SalesOrder records point to one Individual). This is the most common foreign key relationship.
   • One-to-Many (1:N): One record in the source object relates to many records in the target object (e.g., one Individual has many ContactPointEmail records).
   • One-to-One (1:1): Exactly one record in the source relates to one record in the target (e.g., Individual to an extended demographic profile table).

Downstream Impact on the Segment Builder Canvas

The relationship cardinality configured in the data model dictates how fields appear and behave in the Segment Builder:

• Direct Attributes (1:1 and N:1):
  • When segmenting on the Individual DMO, any relationship where Individual is on the "One" side (or 1:1) is treated as a Direct Attribute.
  • Direct attributes represent single-value attributes of the individual (e.g., Individual.BirthDate, Individual.LastName, or Account.BillingCity if linked N:1).
  • Segment logic evaluates these as simple boolean comparisons (e.g., State = 'CA').
• Related Attributes (1:N):
  • Any relationship where an Individual points to multiple child records (e.g., Individual ➔ SalesOrder, Individual ➔ WebsiteClick) appears under Related Attributes.
  • Because a customer may have dozens or thousands of child records, filtering on Related Attributes requires specifying aggregation criteria:
    • Occurrence count: COUNT >= 3 orders.
    • Value aggregations: SUM(GrandTotalAmount) > 500.
    • Value conditions: At least one related order where OrderStatus = 'Completed' within the last 30 days.

Downstream Impact on Calculated Insights

Calculated Insights use ANSI SQL to aggregate metrics across DMOs. However, SQL queries in Data Cloud cannot execute arbitrary ad-hoc joins between unrelated DMOs!

• If a query attempts to join Individual__dlm and VehicleWarranty__dlm, an explicit relationship path must exist in the Data Model Canvas between those two objects (or through an intermediate object).
• If the relationship is missing or configured with inverted cardinality, the Calculated Insight validation parser will fail with a "No relationship path found" error.

---

Critical Exam Traps & Consultant Pitfalls

[!WARNING] Exam Trap 1: The Incompatible Data Type Trap An external transactional log stores purchase timestamps as text strings: "2026-09-21 14:30:00". A junior admin attempts to map this source DLO field directly to SalesOrder__dlm.OrderedDate__c (DateTime) on the mapping canvas.

Why it fails: Data Cloud mapping requires identical primitive types. The mapping line will be rejected. The consultant must create an Ingestion Formula Field using date parsing functions (or a Batch Transform) to convert the text to DateTime before mapping to the DMO.

[!CAUTION] Exam Trap 2: The Unmapped Primary Key Deployment Failure A team maps 25 customer demographic fields from a CRM Contact DLO to Individual__dlm, but forgets to map the CRM Contact ID to Individual__dlm.Id__c.

Why it fails: The Data Mapping Canvas enforces a strict validation rule: a DMO mapping cannot be deployed or saved if the target DMO's primary key (Id__c) is unmapped. Deployment will be permanently blocked until a valid unique text field is mapped to Id__c.

[!NOTE] Exam Trap 3: The Missing Relationship Link in the Segment Canvas A consultant maps an external survey results DLO to a custom DMO SurveyResponse__dlm. Later, the marketing team complains that SurveyResponse__dlm does not appear anywhere in the Segment Builder when building an audience on Individual.

The Root Cause: Creating and mapping a custom DMO is only half the job! You must also navigate to the Data Model canvas, select SurveyResponse__dlm, and explicitly define a Relationship linking SurveyResponse__dlm.RespondentPartyId__c (N:1) to Individual__dlm.Id__c. Without this relationship definition, the Segment engine cannot traverse from the segment anchor to the survey records.