7.1 Customer 360 Canonical Data Model & Subject Areas

Customer 360 Canonical Data Model & Subject Areas

In enterprise customer data architectures, disparate source systems store information using incompatible schemas, disparate naming conventions, and fragmented identity keys. An e-commerce platform may refer to a buyer as a Customer, a CRM system stores the same person as a Contact or Lead, a point-of-sale terminal generates records for a Shopper_ID, and a marketing platform tracks a Subscriber_Key. If ingested directly into analytics or identity engines without normalization, organizations face a combinatorial explosion of custom join logic and brittle point-to-point transformations.

Salesforce Data Cloud overcomes this challenge through canonical data harmonization. Incoming raw data lands first in physical Data Lake Objects (DLOs) and is then mapped into a standardized, industry-aligned semantic schema known as the Customer 360 Data Model. Understanding this canonical foundation, its constituent subject areas, standard taxonomy, and relational architecture is foundational for passing the Salesforce Certified Data Cloud Consultant exam.

---

The Cloud Information Model (CIM) & Canonical Foundation

The Customer 360 Data Model is rooted in the Cloud Information Model (CIM)—an open-source, vendor-neutral data model consortium originally founded by Salesforce, AWS, Genesys, and other enterprise software leaders. The objective of CIM was to establish a standardized, shared language for cloud applications, breaking down enterprise silos across commerce, sales, service, and marketing.

In Data Cloud, the Customer 360 Data Model serves as the internal canonical representation of business entities:

• Abstraction of Source Complexity: Inbound data from AWS S3, Google BigQuery, Snowflake, legacy ERPs, or multiple distinct Salesforce CRM orgs is translated into common business concepts.
• Semantic Uniformity: Regardless of whether a customer's email originates in an Oracle database or a B2C Commerce store, it is harmonized into the canonical ContactPointEmail entity.
• Metadata Suffix (__dlm): In Data Cloud's metadata architecture, canonical Data Model Objects are designated by the __dlm API suffix (Data Lifecycle Model / Data Lakehouse Model). This distinguishes them from raw Data Lake Objects (__dll), custom CRM objects (__c), and staging tables.

┌────────────────────────────────────────────────────────────────────────┐
│                     RAW INGESTION (DISPARATE SOURCES)                  │
│  - Salesforce CRM: Contact (Id, Email, Phone, MailingStreet)           │
│  - Marketing Cloud: Subscriber (SubscriberKey, EmailAddress, Status)   │
│  - E-Commerce Store: Customer_JSON (cust_uuid, billing_addr, mobile)   │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │ Data Mapping Canvas
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│                CUSTOMER 360 CANONICAL DATA MODEL (__dlm)                │
│  - Party Anchor: Individual__dlm (Id__c, FirstName__c, LastName__c)    │
│  - Channels: ContactPointEmail__dlm, ContactPointPhone__dlm            │
│  - Addresses: ContactPointAddress__dlm                                 │
│  - Transactions: SalesOrder__dlm, SalesOrderProduct__dlm               │
└────────────────────────────────────────────────────────────────────────┘

---

Core Subject Areas in Data Cloud

The Customer 360 Data Model organizes hundreds of standard DMOs into logical business groupings known as Subject Areas. Each subject area encapsulates a specific domain of customer data, complete with pre-defined relationships, primary keys, and foreign keys.

1. Party Subject Area

The Party subject area represents individuals, organizations, and legal entities, along with their associated contact mechanisms and identification credentials. It is the foundational subject area for customer unification.

• Individual (Individual__dlm): Models individual humans (consumers, prospective buyers, patients, citizens).
• Account (Account__dlm): Models business accounts, legal organizations, households, or commercial entities.
• Contact Points: Channel-specific contact records linked to an Individual or Account (Email, Phone, Postal Address, Mobile Device App).
• Party Identification (PartyIdentification__dlm): Stores external identification keys (e.g., Driver's License number, SSN/National ID, Passport, Loyalty Member Number) to bridge external identifiers back to the party.

2. Engagement Subject Area

The Engagement subject area captures behavioral interactions, transactional events, digital touchpoints, and time-stamped telemetry generated by individuals or accounts.

• Sales Order (SalesOrder__dlm): Transaction header representing a commercial purchase or checkout.
• Sales Order Product (SalesOrderProduct__dlm): Line items associated with a sales order.
• Browsing & Digital Engagement: DeviceApplication__dlm, WebSession__dlm, SoftwareApplication__dlm for digital events.
• Communication Engagement: EmailEngagement__dlm, SMSMessagingEngagement__dlm for outbound and inbound marketing touchpoints.

3. Product Subject Area

The Product subject area catalogs the goods, physical merchandise, software licenses, and billable services offered by an enterprise.

• Goods Product (GoodsProduct__dlm): Physical tangible inventory or retail merchandise.
• Master Product (MasterProduct__dlm): High-level product catalog definitions grouping variations.
• Product Category (ProductCategory__dlm): Hierarchical taxonomies and merchandise categories.

4. Loyalty Subject Area

The Loyalty subject area models customer rewards programs, tier structures, accrued points balances, and redemption vouchers.

• Loyalty Program Member (LoyaltyProgramMember__dlm): Individual enrolled in a rewards program.
• Loyalty Tier (LoyaltyTier__dlm): Classification levels (e.g., Gold, Platinum, Diamond).
• Loyalty Ledger (LoyaltyLedger__dlm): Transactional ledger of points credited, debited, or expired.

5. Privacy & Consent Subject Area

Data Cloud integrates consent management directly into the canonical architecture to support global privacy mandates (GDPR, CCPA/CPRA, HIPAA).

• Contact Point Type Consent (ContactPointTypeConsent__dlm): Channel-level opt-in/opt-out status (e.g., consent to receive SMS communications).
• Data Privacy (DataPrivacy__dlm): Broad legal basis flags, right-to-be-forgotten status, and processing restrictions.

Subject Area Comparison Matrix

---

Standard DMO Taxonomy & Object Anatomy

To pass the certification exam, consultants must possess a detailed working knowledge of standard DMO names, their primary keys, foreign keys, and structural relationships.

The Party Model & Contact Point Decoupling

In legacy CRM systems (such as standard Salesforce Sales Cloud), a Contact record often combines the person's name, email, mobile phone, and mailing address into a single flat row. In contrast, the Customer 360 Data Model employs a normalized, decoupled architecture:

                          ┌───────────────────────┐
                          │    Individual__dlm    │
                          │  PK: Id__c            │
                          └───────────┬───────────┘
                                      │ 1:N
        ┌─────────────────────────────┼─────────────────────────────┐
        │ 1:N                         │ 1:N                         │ 1:N
        ▼                             ▼                             ▼
┌───────────────────────┐   ┌───────────────────────┐   ┌───────────────────────┐
│ ContactPointEmail__dlm│   │ ContactPointPhone__dlm│   │ContactPointAddress__dl│
│ PK: Id__c             │   │ PK: Id__c             │   │ PK: Id__c             │
│ FK: PartyId__c        │   │ FK: PartyId__c        │   │ FK: PartyId__c        │
│ EmailAddress__c       │   │ FormattedNumber__c    │   │ AddressLine1__c       │
└───────────────────────┘   └───────────────────────┘   └───────────────────────┘

• Individual__dlm: The master entity representing the human being. Contains demographic attributes such as FirstName__c, LastName__c, BirthDate__c, Gender__c, and Salutation__c. Primary Key: Id__c.
• ContactPointEmail__dlm: Represents email addresses. Key fields: Id__c (PK), PartyId__c (FK pointing to Individual__dlm.Id__c), EmailAddress__c, OptInStatus__c, EmailType__c (e.g., Work, Personal).
• ContactPointPhone__dlm: Represents phone and SMS channels. Key fields: Id__c (PK), PartyId__c (FK pointing to Individual__dlm.Id__c), TelephoneNumber__c, FormattedE164PhoneNumber__c, IsSMSCapable__c.
• ContactPointAddress__dlm: Represents physical postal locations. Key fields: Id__c (PK), PartyId__c (FK pointing to Individual__dlm.Id__c), AddressLine1__c, City__c, StateProvince__c, PostalCode__c, Country__c.
• DeviceApplication__dlm: Represents digital application instances, mobile push tokens, or web clients. Key fields: Id__c (PK), PartyId__c (FK), DevicePlatform__c, ApplicationName__c, AppVersion__c.

Commerce & Transactional Taxonomy

• SalesOrder__dlm: Encapsulates transaction headers. Key fields: Id__c (PK), SoldToPartyId__c (FK pointing to Individual__dlm.Id__c or Account__dlm.Id__c), OrderNumber__c, OrderedDate__c, GrandTotalAmount__c, OrderStatus__c.
• SalesOrderProduct__dlm: Line items representing specific items purchased. Key fields: Id__c (PK), SalesOrderId__c (FK pointing to SalesOrder__dlm.Id__c), GoodsProductId__c (FK pointing to GoodsProduct__dlm.Id__c), OrderQuantity__c, TotalLineAmount__c.
• GoodsProduct__dlm: Catalog item master. Key fields: Id__c (PK), Name__c, ProductCode__c, ProductDescription__c.

Standard DMO Reference Matrix

---

Primary Keys and Foreign Keys in Standard DMOs

Relationships in Data Cloud are modeled through explicit Primary Key (PK) to Foreign Key (FK) connections:

Primary Key Rules

1. Text Data Type Only: All primary keys in Data Cloud DMOs must be of data type Text.
2. Row Uniqueness: The primary key must be globally unique across all records within that DMO.
3. Source Key Preservation: While the PK in a DLO reflects the source identifier (e.g., 003xx00000abcdeAAA), when mapping to a DMO, consultants must ensure that if multiple source systems map into the same DMO, key collisions do not occur. Prepended source prefixes (e.g., SFDC_NA_003xx...) created via ingestion formulas should be mapped directly into the DMO's Id__c.

Foreign Key Modeling Patterns

• PartyId__c as the Universal Relational Glue: In the Party model, ContactPointEmail__dlm, ContactPointPhone__dlm, ContactPointAddress__dlm, and DeviceApplication__dlm all contain a foreign key field named PartyId__c. This field MUST be mapped to the identifier representing the parent party (Individual__dlm.Id__c or Account__dlm.Id__c).
• SoldToPartyId__c for Transactions: In the Engagement subject area, transactions tie back to the purchasing entity via SoldToPartyId__c. Mapping this field establishes the relationship required for the Segment Canvas to query purchase behaviors (e.g., "Find all Individuals who spent over $500 in the last 30 days").

---

Consultant Design Philosophy: Why Map to Standard DMOs Whenever Possible?

One of the most heavily tested principles on the Data Cloud Consultant exam is architectural restraint: always map source data to standard Customer 360 DMOs rather than creating custom DMOs, unless the data domain has no equivalent in the Cloud Information Model.

Why does Salesforce mandate this design philosophy?

1. Identity Resolution Engine Exclusivity

Data Cloud's native Identity Resolution engine operates exclusively on standard Profile DMOs: Individual__dlm, ContactPointEmail__dlm, ContactPointPhone__dlm, ContactPointAddress__dlm, and PartyIdentification__dlm.

• If a consultant creates a custom DMO named Customer_Profile__dlm and maps CRM Contacts into it, Identity Resolution cannot process those records.
• The platform will not generate UnifiedIndividual__dlm or unified contact point bridge tables for custom entities.

2. Pre-Built Calculated Insights & Einstein Features

Salesforce delivers pre-packaged Calculated Insights, RFM (Recency, Frequency, Monetary) models, predictive churn scores, and Einstein AI recommendations designed specifically to execute against standard DMO schemas (such as SalesOrder__dlm and Individual__dlm). Mapping into non-standard objects breaks these out-of-the-box analytical models, forcing data engineers to write complex custom SQL scripts from scratch.

3. Out-of-the-Box Activation Paths

Activation targets—such as Marketing Cloud Engagement, Service Cloud, and external advertising platforms (Google Ads, Meta)—rely on standard canonical models. Marketing Cloud activation packages expect standard contact points (ContactPointEmail, ContactPointPhone) to route subscriber attributes and channel preferences accurately.

4. Upgradeability and Maintenance

As Salesforce enhances Data Cloud with seasonal releases, new features and schema optimizations are automatically applied to standard CIM entities. Custom DMOs incur ongoing technical debt, requiring manual schema maintenance and custom relationship management.

[!IMPORTANT] The Standard DMO Rule of Thumb Always extend before creating! If an inbound source attribute (e.g., Loyalty_VIP_Flag__c) does not exist on Individual__dlm, add a custom field to the standard Individual DMO. Do NOT create a custom DMO simply to hold non-standard attributes.