SfSkills Domains Docs GitHub

Home / data / data-cloud-data-model-objects

data-cloud-data-model-objects

Use when designing or managing Data Model Objects (DMOs) in Salesforce Data Cloud — covers DMO schema design, subject area governance, data relationships between DMOs, XMD (extended metadata) layer management, data transforms (streaming vs. batch), and mandatory DMO requirements for identity resolution. NOT for configuring source connectors or the DLO-to-DMO ingestion mapping — use data/data-cloud-data-streams. NOT for overall Data Cloud architecture, activation targets or segmentation strategy — use architect/data-cloud-architecture.

Open the skill folder on GitHub

Data Cloud Data Model Objects

This skill activates when a practitioner needs to design or manage Data Model Objects (DMOs) in Salesforce Data Cloud. DMOs are the semantic layer of the Customer 360 Data Model — they are logical groupings of data stored in Data Lake Objects (DLOs) and organized into subject areas. This skill covers DMO schema design, mandatory DMOs for identity resolution, the XMD (extended metadata) layer for field formatting, and the data transform types that can create or populate DMOs.

Before Starting

Gather this context before working on anything in this domain:

Core Concepts

Where This Sits: The "Harmonize" Stage

Mapping DLO fields onto DMOs is what Salesforce officially calls harmonization. The Data Cloud (now branded Data 360) lifecycle runs: Connect and Ingest → Transform and Model → Unify and Enhance → Analyze and Act. Harmonization is the Transform and Model stage — Salesforce describes it as "harmonize data from those different sources into a standard data model—the Customer 360 Data Model." At the product level, Data 360 lets you ingest, harmonize, unify, and analyze streaming and batch data, so "harmonize your data" and "harmonization stage" are the vocabulary a practitioner will bring to exactly the DMO-mapping work this skill covers.

Operationally, harmonizing is the DLO → DMO field mapping described below: "Data mapping is the process of connecting fields in your DLOs to the standardized fields within the Customer 360 Data Model DMOs." The point of harmonizing to a shared model is downstream interoperability — "This model harmonizes disparate data sources, allowing you to draw insights and unify, segment, and activate your data." Harmonization happens before identity resolution: key attributes like names, IDs, email addresses, and phone numbers are mapped during harmonization precisely because they are what identity resolution later uses to link an individual's data into a unified profile (see the five mandatory DMOs below).

Do not confuse this with the Harmonization Center. That is a separate, similarly-named feature that lives in Marketing Cloud Intelligence (formerly Datorama), not in Data Cloud / Data 360. The Harmonization Center manages naming-convention patterns, classification rules, and harmonized dimensions for marketing analytics data — it has nothing to do with DLO-to-DMO field mapping. If a request references the "Harmonization Center," it is a different product and outside this skill's scope.

DMO Architecture: DLO → DMO Layer

Data Cloud stores raw ingested data in Data Lake Objects (DLOs). DMOs are a semantic abstraction layer on top of DLOs:

Field mapping from DLO to DMO is configured in the Data Stream setup. This mapping determines which DLO fields populate which DMO fields. Salesforce frames this as "DMOs are created by mapping DLOs into standardized groupings" that then "provide physical or virtual views of the underlying data." The target schema is the canonical Customer 360 Data Model — "the standard data model used by Data 360 to aid in data modeling and extensibility across platforms."

Standard connectors can pre-wire the mapping. When you ingest through a standard connector, a data bundle automates part of this work: "after a data stream is deployed, the data bundle automatically maps source objects from the source to a DMO in Data 360." You can then add or customize those mappings to fit the business. For source objects that have no standard DMO equivalent, you still do the mapping by hand — see Pattern 1.

When harmonizing DLO fields that carry primary or foreign keys, configure key qualifiers (fully qualified keys). Salesforce notes this lets Data 360 "accurately interpret data ingested from different sources, ensuring each record has a unique identifier and preventing misinterpretation during queries, segmentation, or calculated insights." Unqualified keys can collide across sources once harmonized into a shared DMO.

Five Mandatory DMOs for Identity Resolution

Identity resolution in Data Cloud requires data to be mapped to specific standard DMOs:

DMOPurpose
IndividualUnified customer/person record
Party IdentificationExternal IDs linking a person to source systems
Contact Point EmailEmail addresses linked to Individual
Contact Point PhonePhone numbers linked to Individual
Contact Point AddressPhysical addresses linked to Individual

Data streams that omit field mappings to these DMOs cannot contribute to unified identity profiles. The identity resolution ruleset operates exclusively on these five DMOs.

XMD: Extended Metadata Layer

XMD controls how Data Cloud fields are displayed: labels, formatting, data type hints, and measure/dimension classification. It has three immutable tiers:

Attempting to update System XMD fields via the REST API returns an error. Identify the XMD type before attempting to modify it.

Streaming vs. Batch Transforms

Data transforms are the "data prep and transformations" mechanism the Data 360 lifecycle uses to prepare and clean data before it is modeled and unified — the same work this skill frames as the Transform and Model stage. Two transform types create or populate DMO records from DLO data:

Streaming Transforms:

Batch Transforms:

Batch transform node types (visual editor): Batch transforms are built in a drag-and-drop visual editor — "you drag and drop nodes to create the data you need." The available node types are:

NodePurpose
InputSource data — reads from a DLO or a DMO
OutputWrites the transformed result to a DLO or a DMO
AggregateRolls data up to a higher granularity (sum, count, average)
AI FunctionsEnriches records using predictive models
AppendCombines rows from multiple sets of data
FilterRemoves unnecessary rows from a dataset
JoinMerges two data branches on matching key fields
TransformCalculations, string manipulation, and data formatting
UpdateReplaces values when key pairs align across sources

Because the Output node targets a DLO or a DMO directly, a batch transform is one of the supported paths for populating a DMO — the transformed result can land straight in the modeled layer. Streaming transforms, by contrast, cannot join or aggregate, so any DMO population requiring cross-source logic must go through a batch transform.

Common Patterns

Pattern 1: Custom DMO Schema Design

When to use: Onboarding a new data source that doesn't map to any existing standard DMO — e.g., a custom loyalty transaction object.

How it works:

  1. Define the DMO name, API name, and subject area assignment
  2. Identify the source DLO(s) and define field mappings (source field → DMO field)
  3. Determine if the DMO needs a relationship to another DMO (e.g., linking loyalty transactions to the Individual DMO)
  4. Create only one data relationship per field pair — multiple relationships between the same two DMO fields are not allowed
  5. Map identity-relevant fields (email, phone, address) to the five mandatory DMOs in a separate data stream if they exist in the source

Why not use SOQL to query the DMO: DMOs are columnar stores, not Salesforce objects. SOQL does not work against DMO data. Use the Data Cloud Query API with ANSI SQL to query DMO records.

Pattern 2: Main XMD Update for Field Label Customization

When to use: Field labels in a Data Cloud dataset or DMO need to be renamed for business-friendly display without modifying the underlying field API name.

How it works:

  1. Retrieve the current Main XMD: GET /services/data/v{version}/wave/datasets/{datasetId}/xmds/main
  2. Modify the fields array in the XMD JSON: update label, alias, or formatting properties for the target field
  3. Submit the updated XMD: PATCH /services/data/v{version}/wave/datasets/{datasetId}/xmds/main
  4. Validate the change by querying the dataset in CRM Analytics or Data Cloud interface

Why not edit System XMD: System XMD is platform-generated and immutable. PATCH requests targeting System XMD return a 403 error. Always work with Main XMD.

Decision Guidance

SituationRecommended ApproachReason
New data source, identity-relevant fieldsMap to mandatory identity DMOs (Individual, Party ID, Contact Points)Required for identity resolution participation
Cross-source data join for analyticsBatch TransformStreaming transforms support only single DLO; joins require batch
Populate a DMO from transformed multi-source dataBatch Transform with an Output node targeting the DMOOutput writes to a DLO or DMO; batch supports the joins/aggregations streaming cannot
Near-real-time enrichment, single sourceStreaming TransformFaster execution; no join needed
Trigger a batch transform from an automationFlow Run Batch Data Transform actionRuns a batch transform on demand inside an orchestration instead of only on schedule
Field label/format customizationPATCH Main XMD via REST APIOnly Main XMD is modifiable; System XMD is immutable
Querying DMO dataData Cloud Query API (ANSI SQL)SOQL does not work against DMO objects
Relationship between two DMOsOne relationship per field pair maximumPlatform limit: multiple relationships on same field pair not supported
  1. Inventory source data schema — Document all entities, fields, data types, and relationships in the source system.
  2. Map to Customer 360 Data Model subject areas — Identify which standard DMOs the source data fits. Create custom DMOs only for entities with no standard DMO equivalent.
  3. Design mandatory DMO mappings for identity resolution — Confirm that identity-relevant fields (email, phone, address, external IDs) are mapped to the five mandatory DMOs.
  4. Define data relationships — Document which DMOs need relationships. Enforce the one-relationship-per-field-pair limit during design.
  5. Select transform type — For each DMO population path, choose streaming (single source, near-real-time) or batch (multi-source join, scheduled).
  6. Design XMD customization — Identify which fields need label changes or formatting updates. Plan Main XMD PATCH calls for each.
  7. Validate with Data Cloud Query API — After DMO population, run ANSI SQL queries via the Data Cloud Query API to confirm field values and relationship traversal.

Review Checklist

Salesforce-Specific Gotchas

  1. DMOs do not support SOQL — DMOs are columnar stores in the Data Cloud data lake, not Salesforce objects in the CRM object model. SOQL queries against DMO API names return errors or empty results. All DMO data access requires the Data Cloud Query API with ANSI SQL syntax.
  2. System XMD is immutable — PATCH against it returns 403 — System XMD is auto-generated by the platform and cannot be modified. Main XMD is the correct target for field customization. Always retrieve the XMD type before attempting to patch it.
  3. Only one data relationship per field pair between DMOs — You cannot create two separate data relationships between the same pair of fields on two DMOs. If a more complex mapping is needed, it must be modeled as a different field pairing or through a transform.

Output Artifacts

ArtifactDescription
DMO schema design documentEntity list with subject area, field definitions, and relationship map
Mandatory DMO mapping checklistConfirmation that all five identity-resolution DMOs are mapped
Transform type selectionStreaming vs. batch decision for each DMO population path
XMD update specificationField labels, aliases, and formatting changes as PATCH payload

Package files