7.1 Customer 360 Canonical Data Model & Subject Areas

Salesforce Certified Data 360 Consultant formerly Data Cloud Consultant

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Solution Overview & Enterprise Value

1.1 Enterprise Customer 360 & Data Cloud Business Value 1.2 Architectural Foundation: Zero-Copy, Hyperforce, Lakehouse & Data Pipeline 1.3 Platform Terminology, Core Entities & Data Lifecycle Stages 1.4 Data 360's Foundational Role in Predictive & Generative AI

2 Chapter 2: Ethics, Privacy & Governance Fundamentals

2.1 Regulatory Compliance, Data Privacy & Ethics in Customer Data 2.2 Consent Management & Preference Enforcement in Data Cloud 2.3 Data Retention, Deletion, and Privacy Right-to-be-Forgotten (RTBF)

3 Chapter 3: Security, Permissions & Tenant Architecture

3.1 Standard Permission Sets, User Roles & Functional Access 3.2 Data Spaces Architecture, Resource Allocation & Tenant Isolation

4 Chapter 4: Administration, Monitoring & Lifecycle Management

4.1 Data Kits & Package Automation for Cross-Org Deployment 4.2 Auditing, Status Monitoring, Error Logs & Data Explorer 4.3 Sandboxes, Change Management & Metadata Deployment

5 Chapter 5: Ingestion Connectors & Source Integration

5.1 Standard Bundles & Salesforce CRM Connectors (Sales/Service/Marketing) 5.2 Cloud Storage (S3, GCS, Azure Blob) & Streaming Ingestion (Web/Mobile SDK, Ingestion API) 5.3 Zero-Copy Data Federation & Snowflake/BigQuery/Databricks Sharing

6 Chapter 6: Data Lake Objects (DLO) & Data Transformations

6.1 DLO Configuration, Primary Keys, Event Time & Data Stream Categories (Profile, Engagement, Other) 6.2 Streaming & Batch Data Transforms: Formula Fields, SQL Transforms & Data Prep Recipes

7 Chapter 7: Data Model Objects (DMO) & Canonical Harmonization

7.1 Customer 360 Canonical Data Model & Subject Areas 7.2 DLO-to-DMO Mapping Patterns, Cardinality & Custom DMO Design 7.3 Data Validation, Schema Maintenance & Field Mapping Best Practices

8 Chapter 8: Identity Resolution Architecture & Match Rules

8.1 Identity Resolution Concepts, Consolidation Rate & Graph Modeling 8.2 Match Rules & Match Criteria: Exact Match vs. Fuzzy Matching (Deterministic & Probabilistic) 8.3 Multi-Party Identification, Anonymous-to-Known Transitions & Contact Point Matching

9 Chapter 9: Reconciliation Rules & Unified Profile Governance

9.1 Reconciliation Rules: Most Frequent, Source Priority & Last Updated 9.2 Unified Profile Schema (Individual & Contact Points) & Resolution Troubleshooting

10 Chapter 10: Segment Architecture & Audience Design

10.1 Segmentation Canvas, Segment Types (Standard UI & Flow) & Query Processing 10.2 Direct vs. Related Attributes, Cardinality & 1:N Filtering Traps 10.3 Segment Schedule, Refresh Frequencies & Exclusion Logic 10.4 Segment Membership Analysis, Population Drift & Sizing Validation

11 Chapter 11: Calculated & Streaming Insights

11.1 Calculated Insights (CI) Architecture, SQL/Builder Syntax & Dimensions vs. Metrics 11.2 Streaming Insights (SI) Architecture, Windowing (Tumbling/Sliding) & Real-Time Signals 11.3 CI vs. SI Architectural Decision Matrix & Performance Optimization

12 Chapter 12: Data Enhancements, Sharing & Analysis

12.1 Referencing Data 360 Data from Other Systems: Enrichments, Related Lists, Data Graphs & APIs 12.2 Reports, Dashboards & Tableau Analysis on Data 360 Data 12.3 Applying Predictive & Generative AI Tooling to Customer Scenarios

13 Chapter 13: Activation Targets & Outbound Activation

13.1 Activation Targets: Marketing Cloud, External Platforms, Cloud Storage & Data Spaces 13.2 Activation Configuration: Audience Mapping, Related Attributes & Payload Optimization 13.3 Activation Schedules, Publishing Cadence & Incremental vs. Full Refresh 13.4 Activation Troubleshooting: Error Logs, Rejection Reasons & Delivery Failures

14 Chapter 14: Real-Time Data Actions & Flow Automation

14.1 Data Action Targets & Webhook/Platform Event Architecture 14.2 Data Cloud-Triggered Flows & Real-Time Business Orchestration 14.3 End-to-End Enterprise Scenario Walkthrough: Ingestion to Closed-Loop Action

7.1 Customer 360 Canonical Data Model & Subject Areas

Key Takeaways Explain This Topic AI

The Customer 360 Data Model is built upon the open-source Cloud Information Model (CIM), providing an extensible canonical data architecture that standardizes customer, engagement, and transactional data across disparate enterprise source systems.

Data Model Objects (DMOs) carry the __dlm API suffix, representing logical, semantic entities organized into five core Subject Areas: Party, Engagement, Product, Loyalty, and Privacy & Consent.

The Party subject area decouples individual human identity (Individual__dlm) from contact channels (ContactPointEmail__dlm, ContactPointPhone__dlm, ContactPointAddress__dlm, DeviceApplication__dlm), linked via PartyId__c foreign keys in a 1:N relational pattern.

Standard DMOs unlock out-of-the-box Salesforce Data Cloud capabilities—including automated Identity Resolution rulesets, pre-built Calculated Insights, standard e-commerce metrics, and pre-configured Activation paths—that are unavailable to unmapped or custom entities.

Primary Keys (Id__c) in DMOs must maintain absolute uniqueness across all mapped sources, requiring source prefixing or composite key formulas at ingestion to prevent cross-source entity collisions in the harmonized model.

Last updated: September 2026

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

Subject Area Primary Purpose Core Standard DMOs Default Category Downstream Utilization

Party Who the customer or account is Individual__dlm , Account__dlm , ContactPoint*__dlm Profile Identity Resolution, Unified 360 Profiles, Master Data

Engagement What the customer does (behavior & sales) SalesOrder__dlm , DeviceApplication__dlm , EmailEngagement__dlm Engagement Calculated Insights (Spend, Recency), Behavioral Segments

Product What items or services are offered GoodsProduct__dlm , MasterProduct__dlm , ProductCategory__dlm Other Segment product filters, Next Best Action recommendation

Loyalty How the customer is rewarded LoyaltyProgramMember__dlm , LoyaltyTier__dlm , LoyaltyLedger__dlm Profile / Other Tier-based segmentation, Churn prediction, Loyalty Activation

Privacy & Consent What communications are legally permitted ContactPointTypeConsent__dlm , DataPrivacy__dlm Profile Activation filtering, Consent enforcement, Regulatory audits

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

DMO Label API Name Category Primary Key Critical Foreign Keys
Individual Individual__dlm Profile Id__c N/A (Root Anchor)
Contact Point Email ContactPointEmail__dlm Profile Id__c PartyId__c ➔ Individual__dlm.Id__c
Contact Point Phone ContactPointPhone__dlm Profile Id__c PartyId__c ➔ Individual__dlm.Id__c
Contact Point Address ContactPointAddress__dlm Profile Id__c PartyId__c ➔ Individual__dlm.Id__c
Party Identification PartyIdentification__dlm Profile Id__c PartyId__c ➔ Individual__dlm.Id__c
Sales Order SalesOrder__dlm Engagement Id__c SoldToPartyId__c ➔ Individual__dlm.Id__c

Sales Order Product SalesOrderProduct__dlm Engagement Id__c SalesOrderId__c ➔ SalesOrder__dlm.Id__c , GoodsProductId__c ➔ GoodsProduct__dlm.Id__c

Goods Product GoodsProduct__dlm Other Id__c N/A (Master Catalog Anchor)
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

Text Data Type Only : All primary keys in Data Cloud DMOs must be of data type Text .

Row Uniqueness : The primary key must be globally unique across all records within that DMO.

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.

Loading diagram... Customer 360 Canonical Architecture: Subject Areas, DMO Relationships, and Downstream Capabilities