Data 360 modeling and harmonization convert source-specific records into a standardized customer data model that can support identity resolution, segmentation, calculated insights, activation, reporting, and AI grounding. Source data first arrives in Data Lake Objects (DLOs). Mapping relates DLO fields to Data Model Objects (DMOs), which represent harmonized business entities such as Individual, Account, contact points, or engagement records.
Salesforce renamed Data Cloud to Data 360 in October 2025, while older internal URLs may still use Data Cloud naming. The current Salesforce Certified Data 360 Consultant exam gives significant weight to source ingestion, harmonization, unification, administration, and data utilization, making modeling one of the central platform skills.
Inventory source systems before mapping
Start with a source inventory: systems, entities, keys, field definitions, update cadence, sensitivity, and data-quality known issues. Mapping directly in the UI without this preparation encourages one-off choices that become difficult to reconcile later.
The broader data engineering principle applies: understand the source contract before designing the target.
Understand Data Lake Objects and Data Model Objects
A DLO is the landing representation of ingested source data. A DMO is the harmonized model used by downstream Data 360 features. Mapping does not simply rename fields; it establishes how source semantics correspond to the standardized model.
Custom DMOs can fill gaps where standard objects do not represent the business requirement, but standard objects should be used where they fit because many Data 360 features expect specific relationships and party-model structures.
Map primary keys correctly
Data 360 requires primary-key mappings for many DMOs, and engagement objects also require event date/time fields. Primary keys must uniquely identify the source entity at the correct grain.
A weak key can cause duplicates, failed relationships, and poor identity-resolution outcomes. Do not choose a convenient field merely because it is populated; verify uniqueness and stability over time.
Build relationships intentionally
DMO relationships determine how records connect for segmentation, identity resolution, and analysis. Customer engagement events should connect to the right Individual or Account context through mapped identifiers.
Relationship design should reflect business truth rather than source-system shortcuts. If one source uses a temporary ID and another uses a durable master ID, the harmonized model should preserve enough information to relate both correctly.
Normalize source variation before unification
Phone numbers, email addresses, names, addresses, and identifiers often use inconsistent formats. Data cleansing and transform features can standardize these values before identity resolution and segmentation.
Normalization should preserve the original source where investigation may require it. A cleaned value is useful for matching, but the raw value can explain why records did or did not align.
Model party data for identity resolution
Identity resolution depends on required party mappings. Salesforce documentation calls out the Individual object and contact point or Party Identification objects as foundational for person-level unification.
Plan these mappings before building rulesets. A sophisticated match rule cannot compensate for missing or incorrectly related identity fields.
Model engagement data at the right grain
Engagement data should represent events with clear event time, participant identity, and business meaning. Avoid collapsing event history prematurely if later segmentation or insights depend on sequence, recency, or frequency.
Streaming and batch transforms can reshape source events into useful Data 360 structures, but transformation logic should remain reproducible and version-controlled.
Custom fields and DMOs should be used carefully. Extending the standard model is appropriate when the business has attributes not represented by default objects. However, every custom object or field adds documentation, relationship, and maintenance burden.
Before creating a custom DMO, confirm that a standard object cannot represent the concept and that downstream features support the intended usage.
Test mappings before downstream adoption
Validate row counts, required fields, key uniqueness, relationship coverage, and representative source-to-DMO mappings before enabling identity resolution or segmentation. Errors discovered after audiences and agents depend on the model are much more expensive to correct.
The Agentforce Specialist path is a natural adjacent relationship because grounded agents increasingly depend on Data 360 indexes, retrievers, and harmonized data whose quality originates in this modeling layer.
Govern the model as a shared contract
DMOs should have owners, definitions, source lineage, sensitivity classification, and change procedures. A field-name change can affect segments, calculated insights, activations, and AI grounding even if ingestion continues successfully.
The Salesforce Data 360 model becomes valuable when teams can reuse it safely across use cases. Harmonization is not about forcing every source into one shape; it is about creating consistent entities and relationships that downstream systems can trust.
Source inventories should include semantic differences, not only technical schemas. Two systems may both have a field named status while one means marketing lifecycle and the other means account service state. Mapping both to one DMO field because the names match can create subtle business corruption.
Data types need intentional conversion. A numeric source identifier may be stored as a string in the harmonized model because leading zeros or formatting carry business meaning. Type compatibility is necessary for mapping, but semantic compatibility is the real requirement.
Standard DMOs provide value because downstream Data 360 features understand common party, engagement, and contact-point relationships. Extending a standard DMO with custom fields is often preferable to creating an entirely new object when the entity is fundamentally the same.
Custom DMOs are appropriate for business concepts outside the standard model, but they need explicit relationships to the rest of the graph. An isolated custom object may ingest successfully yet remain unusable for segmentation or identity resolution because no meaningful path connects it to Individual or Account.
Data spaces can introduce another governance boundary. If different brands, regions, or business units use separate spaces, mapping design should make clear whether the same source can be reused and how cross-space access or harmonization is controlled.
Transformations should be separated from mapping where complex cleansing is needed. Batch or streaming transforms can standardize data before it maps into DMOs. This keeps mapping focused on semantic alignment rather than becoming an implicit transformation layer that is difficult to test.
Streaming transforms require operational monitoring because they run continuously and can propagate source defects quickly. Batch transforms can be easier to replay for large historical corrections. Choose processing mode from freshness and recovery requirements.
Engagement data modeling should preserve event time and event identity. A web click, purchase, service case update, and email engagement have different semantics but all need enough temporal context to support recency, frequency, and journey analysis.
Contact-point models need normalization and provenance. An email address can appear in multiple source systems with different verification or consent states. Preserve source and priority so identity resolution and activation can choose the correct contact point for a business use case.
Mapping changes can have a wide blast radius. Identity-resolution rules, calculated insights, segments, activations, reports, and Agentforce grounding may all depend on the DMO field. Use dependency review and change communication before altering a heavily used mapping.
Testing should compare a known source record with its DLO and DMO representation. Trace key fields through ingestion, transformation, and mapping to confirm no data-type, normalization, or relationship mistake occurred. This end-to-end sample is often more informative than reviewing configuration screens separately.
Data-quality metrics should be attached to the model: required-field completeness, key uniqueness, relationship coverage, unmapped source fields, invalid categories, and freshness. A harmonized model is only useful when its population meets the assumptions of downstream features.
Governance should distinguish source ownership from DMO stewardship. One team may own a CRM source while another owns the enterprise Individual model. Both need defined responsibilities when source semantics change.
Documentation should use current Data 360 terminology while acknowledging historical Data Cloud names where legacy APIs, URLs, or internal documentation remain. Silent renaming can confuse teams trying to match current product documentation to existing assets.
A mature harmonization layer creates a reusable semantic foundation. It does not erase source differences; it makes those differences explicit and maps them into governed entities whose keys, relationships, definitions, and lineage are stable enough for identity, segmentation, analytics, and AI.
Mapping ownership should be assigned by data domain. Platform administrators can provide standards, but the team that understands a source system is usually best positioned to confirm field meaning, key stability, and valid relationships. Shared stewardship prevents mappings from becoming purely technical guesses.
Source schema changes should trigger contract review. A field that changes from optional to required, text to numeric, or one business meaning to another can invalidate the DMO mapping even if ingestion continues. Monitor source metadata and transformation errors for early warning.
Data transformations should preserve enough lineage to explain derived values. If a DMO field is calculated from several raw attributes, document the rule and transformation version. This is especially important when downstream identity or segmentation depends on the field.
Data model performance matters too. Deep or awkward relationship paths can complicate segmentation and analysis. Use the standard model and direct relationships where business semantics support them instead of creating layers of custom objects for every source-system nuance.
Unstructured data introduces UDLOs and UDMOs, which need their own mapping and governance. When Agentforce retrieval uses unstructured sources, those objects become part of the data foundation even though they are not traditional tabular customer profiles.
Data collaboration and zero-copy sources can introduce external DLOs that reference data stored outside Data 360. The harmonized model should still make source ownership, freshness, and access expectations clear because physical storage location does not remove semantic dependencies.
Development lifecycle should include deployable metadata and validation. Avoid manually rebuilding mappings in production from screenshots or documentation. Use supported packaging and deployment tooling where possible and verify required references after promotion.
When a standard DMO evolves in Salesforce releases, review custom extensions and mappings for compatibility. A current model should use current product terminology and capabilities without breaking existing integrations that still expose historical Data Cloud names.
Model documentation should include examples of valid records and relationship paths. Concrete examples help new engineers understand how a customer, contact point, engagement event, and account relate in the harmonized model without reverse-engineering every DMO.
Data-model changes should be tested against the major downstream consumers—identity resolution, segmentation, calculated insights, activation, and Agentforce grounding—because each may rely on different parts of the same relationship graph.
Harmonization should also preserve auditability. When a downstream user asks why a DMO field has a particular value, the platform team should be able to trace it to the source DLO and transformation logic without relying on tribal knowledge.
That lineage should remain available after the original implementation team moves on.
That continuity is part of treating the model as shared enterprise infrastructure rather than implementation detail.
Shared infrastructure needs that durable semantic ownership.
That ownership should survive source migrations, org changes, and future Data 360 releases.
Keep that stewardship explicit.
Harmonization changes should be treated as shared semantic-contract changes: identify downstream segments, calculated insights, activations, and agents that depend on the affected Data Model Object before publishing the new mapping.