What is the most important tip for working with Data Model Object?

Extend standard DMOs whenever the concept fits. Building a custom DMO for something the standard model already covers means losing access to packaged Customer 360 features that assume the standard schema.

PlatformIntermediate

Data Model Object

Q: What is a DMO in Data Cloud?

DMOs are the canonical data structures in Data Cloud that represent business entities and define the schema for ingested data.

Q: Why do DMOs matter for identity resolution?

DMOs are the foundation for identity resolution because they provide the canonical structure that lets Data Cloud match equivalent records from different sources.

Q: Can you extend the Data Cloud model with custom DMOs?

Custom DMOs let customers extend the canonical model for entities that aren't covered by the standard DMOs.

A Data Model Object (DMO) is the canonical entity in Salesforce Data Cloud that represents a real-world concept like Individual, Account, Email Engagement, or Order.

Hear it

§ 01

Definition

A Data Model Object (DMO) is the canonical entity in Salesforce Data Cloud that represents a real-world concept like Individual, Account, Email Engagement, or Order. DMOs are the harmonization layer above the raw Data Lake Objects (DLOs) that Data Streams produce. The DMO defines a consistent schema across every source system; field harmonization happens via DLO-to-DMO mappings that translate source-specific field names (Sales Cloud Contact.FirstName, Marketing Cloud Subscriber.first_name, external Customer.given_name) into one canonical attribute (Individual.FirstName).

Data Cloud ships a standard set of DMOs covering the most common B2B and B2C entities, called the Customer 360 Data Model. Customers can extend the standard DMOs with custom attributes, build custom DMOs for org-specific concepts, and configure relationships between DMOs that mirror real-world record linking (an Individual is related to many Email Engagements, an Account has many Individuals as Contacts). The DMO is what downstream Data Cloud features (Identity Resolution, Segmentation, Calculated Insights, Activations) query and operate against.

§ 02

How Data Model Objects harmonize cross-source data into the canonical Customer 360 schema

Standard DMOs and the Customer 360 Data Model

Data Cloud ships a curated set of standard DMOs covering Individual, Account, Contact Point Email, Contact Point Phone, Contact Point Address, Email Engagement, Web Engagement, Sales Order, Marketing Campaign, and dozens more. These are the canonical B2B and B2C entities Salesforce documents in the Customer 360 Data Model reference. Each DMO has a stable set of attributes (FirstName, LastName, EmailAddress, EngagementDate) that downstream features assume exist. Building on the standard model is cheaper than rolling your own.

Custom DMOs versus extending standard DMOs

Two ways to add fields. Extending a standard DMO adds custom attributes (Individual.Loyalty_Tier__c) to the existing canonical entity; downstream segments and activations see the new field automatically. Custom DMOs (Subscription, Vehicle, Patient_Encounter) are new entities for concepts not in the standard model; they require explicit relationships back to standard DMOs. Default to extending; only build a custom DMO when the concept genuinely does not fit the standard model.

DLO-to-DMO mapping is where harmonization happens

Each source-system DLO maps to one or more DMOs. Sales Cloud Contact maps to Individual plus Contact Point Email (one source row produces records in multiple DMOs). Marketing Cloud Subscriber maps to Individual plus Contact Point Email plus Email Engagement. Custom field mappings translate source field names to canonical DMO field names. Get the mapping right and Customer 360 is consistent across sources; get it wrong and you have three Individuals for the same person.

Relationships between DMOs

DMOs relate to each other via lookup-style relationships. Individual has many Email Engagements, Account has many Individuals via the Account-Contact bridge, Sales Order has one Account and one Individual buyer. Relationships are defined in the data model configuration and enforced at query time. Segmentation queries traverse relationships ("Individuals who placed more than 3 Sales Orders in the last 90 days"). Get relationships right and queries are intuitive; get them wrong and segmentation produces empty or duplicate results.

Primary key and the unique identifier per DMO

Each DMO requires a primary key. For source-driven DMOs like Email Engagement, the primary key is usually a source-system event ID. For canonical DMOs like Individual, the primary key is generated by Identity Resolution after dedupe across sources. Source DLOs supply candidate IDs; Identity Resolution rules decide which Individual rows merge into a single canonical Individual with one stable Customer Profile ID. The primary key choice underlies everything downstream.

DMO storage and the query layer

DMOs are stored in Data Cloud''s lakehouse storage and queryable via Data Cloud SQL or the segmentation UI. Storage is columnar and partitioned; queries on common filter fields are fast. Wide table scans on rare fields can be slow and expensive. Build segmentation and Calculated Insights on commonly-filtered fields; avoid filtering on attributes the model designer did not expect to be hot. Index hints are not user-configurable.

Versioning and schema evolution

DMO schemas evolve over time as the org adds custom fields and Salesforce ships new standard fields with each release. Schema changes propagate to downstream segments, Calculated Insights, and Activations automatically; existing queries continue to work. Removing or renaming a field is harder; downstream segments referencing the field break. Plan field deprecation carefully or accept rebuild cost on dependent assets.

§ 03

Designing and configuring Data Model Objects

DMO setup is mostly a configuration task in the Data Cloud Data Model area. Decisions about extending standard versus building custom DMOs should happen upfront; reversing them later is expensive.

Review the standard Customer 360 Data Model
Data Cloud, Data Model. The standard DMOs are listed by category (Party, Engagement, Commerce, Marketing). Read the standard schema for each DMO you expect to use. Most use cases fit the standard model with minor extensions.
Decide extend versus custom DMO per concept
For each concept in your data, decide: does it fit a standard DMO (extend) or does it need its own DMO (custom)? Most B2C concepts fit; industry-specific concepts (Insurance Policy, Patient Record) may need custom DMOs.
Build or extend the DMO
For custom: Data Cloud, Data Model, New DMO. Set name, primary key, and field list. For extensions: open the standard DMO, add custom attributes. Both paths land you with a DMO definition ready to receive mappings.
Map source DLOs to the DMO
For each Data Stream that should populate this DMO, configure the DLO-to-DMO mapping. Match source fields to DMO attributes. Set the relationship key for cross-DMO links.
Configure relationships
Define lookup relationships from this DMO to related DMOs (Individual has many Email Engagements). Relationships enable segmentation across DMOs and Calculated Insights that aggregate child records.

Key options

Standard versus custom DMOremember

Standard DMOs follow the Customer 360 model and integrate with packaged features. Custom DMOs handle concepts not in the standard model; require explicit relationship setup.

Primary key fieldremember

Required. Defines uniqueness on the DMO. For canonical entities, often generated by Identity Resolution; for event entities, typically a source-system event ID.

Relationship typeremember

Many-to-one lookup, one-to-many child, or many-to-many bridge. Pick based on real-world cardinality of the related entities.

Field harmonization mappingremember

Per DLO, per field. Maps source-system attribute names to canonical DMO attribute names. The heart of cross-source harmonization.

Gotchas

Wrong DLO-to-DMO mapping is the single most common Customer 360 implementation mistake. Sales Cloud Contact.FirstName and Marketing Cloud Subscriber.first_name must both map to Individual.FirstName or the canonical profile is incomplete.
Custom DMOs require explicit relationships to standard DMOs. Skipping this breaks downstream segmentation across the data model.
Field deprecation breaks dependent segments and Calculated Insights. Plan field changes carefully or accept rebuild cost.
Primary key choice is hard to change after the DMO is in production. The wrong key leaks duplicate canonical records.
Wide scans on rarely-filtered fields are slow and credit-expensive. Build for hot filter fields.

Trust & references

Sources

Cross-checked against the following references.

Data Model Object OverviewSalesforce Help
Customer 360 Data ModelSalesforce Help

Official documentation

Straight from the source - Salesforce's reference material on Data Model Object.

Create a Data Model ObjectSalesforce Help
Data Cloud Data RelationshipsSalesforce Help

Was this entry helpful?

Help us write better definitions. Quick reactions or detailed edit suggestions.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.

Test your knowledge

Q1. What is a DMO in Data Cloud?

Q2. Why do DMOs matter for identity resolution?

Q3. Can you extend the Data Cloud model with custom DMOs?

Discussion

Loading…

Loading discussion…

Back to Dictionary