Customer 360 Data Model: Let's go from Chaotic to Canonical
Standard way to describe a customer
In my previous post, I spoke about how Data Cloud works. Within the segment of ‘Harmonize’, I asked a simple question, ‘Why do we need to Harmonize at all?’, here is the summary of that:
It is because different sources have different schemas. Now you can do point-to-point mapping ie. CRM —> ERP, ERP —> Billing. But wouldn’t be amazing if each system maps once to one model and all the other systems references from it, using one definition? Thus, this idea of canonical reference model came in (Defined as DMO in Salesforce) that is standardized and gives a single, standard way to describe the business entity - like Customer.
Salesforce came with their own canonical reference model and hence they named it - ‘Customer 360 Data Model’.
What does the architecture look like?
Decoupled Schema: This model in a way ‘ignores’ the schema of the data sources and maps diverse Data Lake Objects (DLOs) into a single set of standard Data Model Objects (DMOs).
Subject Area: In order to organize this schema, they group these DMOs into domains known as Subject Area. They are grouped with some objective in mind, example
Party: Who is involved? (e.g., `Individual`, `Contact Point Email`).
Engagement: What happened? (e.g., `Email Open`, `Web Click`).
Sales Orders: What was exchanged? (e.g., `Sales Order`, `Sales Order Product`).
Attribute: Within these objects, there are attributes or simply fields (if you don’t know what fields are, go back to Salesforce 101).
Primary Key and Foreign Key: These are basic concepts of data model. Primary Key: is a value in a data set that uniquely identifies a single record (like CustomerID). Foreign Key: Value in a data set that acts as a common link between different tables. This is the guy that builds relationship between 2 tables.
Normalized: In addition, I found DMOs to be highly normalized. Customer 360 model is not 1 giant flat table but multiple tables connected together. Example: An ‘Individual’ record holds the person’s name, but their email lives in a separate ‘Contact Point Email’ record linked by a foreign key (Party ID)
What does this data model help with?
Identity Resolution: Now that we have 1 standard model, we can match duplicate fields across system (like CellPhone, Mobile_Num_Value) to 1 field (ContactPointPhone.PhoneNumber).
Segmentation: With this data model, when you want to ‘Find all customers who bought shoes from our websites’, you just query the ‘Sales Order’ DMO once.
AI: Now you can train your AI - agentforce, Einstein on this model.
Key DMOs
What are the key DMOs that we must know about?
Individual: The human being. Contains fields like First Name, Last Name, Birth Date.
Contact Point (Email/Phone/Address): How to reach humans. These are separate from the Individual so a single person can have multiple emails or phones without duplicating the person record.
Party Identification: This is a related child object to Individual that handles external references without storing personal details. And then it links back to Individual via foreign key: Party. Here are the fields for this object,
Party Identification ID (`ssot__Id__c`): Unique primary key for the record
Party (`ssot__PartyId__c`): Foreign key linking to the parent Party (e.g., Individual or Account ID)
Identification Number (`ssot__Identificationnumber__c`): The actual ID value for matching (e.g., “DL123456”)
Party Identification Type (`ssot__PartyIdentificationTypeId__c`): Categorizes the ID (e.g., “Government” or “Vendor-Specific”).
