You’ve enabled and activated Data Cloud.

You’ve also set up Data Cloud Data Ingestion.

There’s an ongoing flow of data coming from many sources. Connectors, Data Source Objects, Data Lake Objects.

So now, how does all that data get harmonized and mapped to the Salesforce 360 Data Model so you can actually activate it?

That’s what we’ll cover in this guide.

Data Mapping and the Salesforce Customer 360 Data Model

Data Mapping

Each data source you ingest in Data Cloud comes with its own data schema.

For example, you might have an AWS S3 source Data Lake Object “ShopOrders” and a Cloud Storage Data Lake Object called “EcommerceOrders”.

Both DLOs have an Order field (they both contain Transactional data from your customers), but the schemas might slightly differ:

ShopOrders
OrderID: 001
First Name: Frank
Quantity: 100
Currency: EUR

EcommerceOrders
Ecom_Order_ID: 002
Name: Anne
Qty: 120
Currency: EUR

Mapping means assigning those disparate data source structures to a common data model, normalized.

Salesforce Customer 360 Data Model – Overview

Salesforce Data Cloud comes with a canonical Data Model so your data mapping is seamless:

The Salesforce Customer 360 Data Model.

You can find the full model to view and download here:

Salesforce Customer 360 Data Model – Salesforce Architects Full Diagram:
https://architect.salesforce.com/diagrams/data-models/data-cloud/engagement

Salesforce Customer 360 Data Model – Salesforce Data Cloud Documentation:
https://help.salesforce.com/s/articleView?id=sf.c360_a_c360datamodel.htm&type=5

The idea behind a canonical data model is:

It helps reduce complexities of integrating disparate schemas.
It helps build a standardised single view of each customer.
It serves as a foundational layer so that no matter how custom your data model is, once it is harmonized in Data Cloud, everyone can understand what each object does, what data purpose it has, etc.

From left to right, this would be a representation of how the Data Ingestion and Data Modelling steps help your business drive value:

1. Different Data Sources –> 2. Standard Data Cloud Data Model –> 3. Data Value

In other words, the source data needs to be harmonized so that you can later “do positive ROI stuff” with it, such as Identity Resolution, Segmentation, Activations, Insights, etc.

IMPORTANT
Getting familiar with this canonical data model is part of the Data Strategy you should carry out before you even activate Data Cloud. You need to understand how your source business data will be mapped to this model, if there are any potential issues, edge cases, etc.

Canonical Data Model vs BYO Data Model

A common best practice when working with Salesforce is to leverage Standard Objects as much as possible.

Data Cloud is no exception.

The idea behind a canonical Salesforce data model is that you strategically plan the mapping between your company data and the Customer 360 Data Model so you can make the most out of Data Cloud.

That’s why it’s super important to plan ahead, understand the 360 Customer Data Model, how mapping works, etc.

IMPORTANT
Although Data Cloud is not BYO Data Model, you may extend the capabilities of the canonical data model and add custom objects, but recommendation is to do so only when really necessary.

Data Modelling Phases

Normally, Data Modelling can be done in 2 differentiated phases in a Data Cloud project:

Data Design
Data Build

Data Design

The Data Design Phase should come as a consequence of an initial Data Discovery, of course.

Direction > Speed

For this Data Discovery to be efficient, you will need a clear understanding of the Data Cloud Setup and Provisioning models and considerations, Use Cases requirements and value matrix applied to them, scope of the project, etc.

When it comes to Data Cloud, 80% of a project is strategy and planning.

Assuming the right strategy is already in place (the most important step), the Data Design phase will typically include:

Preparing your data dictionary or data inventory
This means creating an inventory of all your data sources to be ingested into Data Cloud, including their data schema, attributes, value samples for each field, edge cases, Primary and Foreign Keys, API names and labels, etc.
Confirming your Field-Level data mapping requirements
For each data source, check attributes, define what Data Model Object they will be mapped to, ensure data types match when needed, define cardinality of the data relationships, shared keys, Key Qualifiers, etc.

Makes sense, doesn’t it?

First, you gather everything you’ll ingest into Data Cloud and why.
Second, you confirm that data is going to be translated into the Salesforce Data Model.

Data Build

Once the data inventory is in place and you’re 100% sure of the required mappings, the Data Build phase starts.

This includes 3 main points:

Configuration of the data model mappings in Data Cloud
Configuration of Data Relationships
Review required mappings, extra relationships, custom objects extension, etc

Customer 360 Data Model – Subject Areas

The Salesforce Customer 360 Data Model is organised into Subject Areas.

Subject Area: a group of data objects that relate to the same business goal or logical organization

For example:

Engagement data
Sales Orders
Product Information

Each Subject Area is made up of Data Model Objects (DMOs), and each DMO has different Attributes.

A simplified example of this level of organization would be:

1. Subject Area
Product

2. DMOs in “Product” Subject Area:
Brand DMO
Goods Product DMO

3. Attributes in each DMO
Brand DMO
Brand ID
Created Date
Data Source Object
Name
Parent Brand

Goods Product DMO
Brand
Color
Created Date
Gross Weight
Height
Is Installable
Is Returnable

Getting familiar with the different Subject Areas of the 360 Data Model takes time. In the next section, you can find a quick overview of each area and the DMOs included.

DOCUMENTATION
– Please find below the documentation of all the DMOs that are included in the Customer 360 Data Model together with their schemas, API names, etc:
https://developer.salesforce.com/docs/atlas.en-us.c360a_api.meta/c360a_api/c360dm_DataModelObjects.htm
– Check this link for the full list of all the Subject Areas that exist in the 360 Customer Data Model:
https://help.salesforce.com/s/articleView?id=sf.c360_a_data_model_subject_areas.htm&type=5

Subject Area – Case Data Model

This Subject Area covers issues in customer service, such as a support ticket or a fault in a purchased appliance. Find below a breakdown of all the Data Model Objects (DMO) included in this area:

Search:

Data Model Object (DMO)	Description
Individual	This DMO refers to the people who interact with your business: customers, contacts, etc.
Case	This DMO contains the support tickets or cases for your customers, based on different issues, categories of issues, etc.
Account	This DMO contains info about how a party prefers to interact with your business.
Account Contact	This DMO refers to a specific person within an Account, with a specific role.

Subject Area – Engagement Data Model

The Engagement Subject Area refers to all the interactions of a specific party with your business. Some examples of those interactions: purchasing a product, receiving an SMS.

Breakdown of all the DMOs:

Search:

Data Model Object (DMO)	Description
Device	The Device DMO refers to an electronic device from which your business needs to track events or info. E.g: a smartphone, an electric car.
Device Application Engagement	This DMO includes all the collected app info from the Device. It can include data points such as app usage on a smartphone, for instance.
Device Application Template	This DMO includes the standard format for the messages on applications of the devices.
Email Engagement	This DMO includes info about data captured about an engagement from different sources.
Email Template	The DMO that contains the template or standard format of email messages which can later be customised with personalization, etc.
Engagement Topic	The DMO for the topic or theme of the engagement. E.g: campaigns, promotions.
Product Browse Engagement	A DMO that includes the data events gathered from a consumer's behaviour when viewing products, searching for them, visiting PDP pages, etc.
Product Order Engagement	The DMO that includes all the data about a consumer's order data when shopping. E.g: currency, total amount, etc.
Shopping Cart Engagement	The DMO that includes all the data events gathered around Shopping Cart behaviour. E.g: products added, removed from cart.
SMS Engagement	This DMO includes data about engagement with an SMS message.
SMS Template	The DMO that contains the template or standard format of SMS messages.
Web Search Engagement	The DMO for engagement data points around web search. E.g: browser, country.
Website Engagement	The DMO that contains any data related to the user's behaviour on your website. E.g: view events, clicks, etc.

Subject Area – Loyalty Data Model

The Loyalty Subject Area groups the objects relating to Loyalty programs and recognition programs for customers.

Breakdown of all its DMOs:

Search:

Data Model Object (DMO)	Description
Account Contact	This DMO refers to the contact that is assigned to a loyalty program member.
Loyalty Aggregated Point Expiration Ledger	This DMO, within a Loyalty Program context, gathers all the points that a loyalty program member has, based on currency and expiration policies of points.
Loyalty Benefit	This DMO refers to a benefit or perk which is part of a loyalty program. E.g: gifts you get from points redeemed.
Loyalty Benefit Type	The DMO which specifies the types of Loyalty Benefits available to loyalty program members.
Loyalty Journal Subtype	This DMO refers to a subtype of a Journal Type. E.g: product review.
Loyalty Journal Type	This DMO includes information about the different transaction methods available in the program, be it for points redemption or accrual.
Loyalty Ledger	This DMO records the points given or taken to/from a program member across transactions.
Loyalty Member Currency	This DMO includes the info about the value a loyalty program member selects to receive points as (e.g: USD, miles).
Loyalty Member Tier	This DMO is the benefit tier to which a program member is assigned.
Loyalty Partner Product	The DMO which has info about a product offered by a partner within the loyalty program.
Loyalty Program Partner Promotion	This DMO contains all the info about the promotions that the loyalty program has in cooperation with partners.
Loyalty Program	The DMO which refers to the marketing strategy of having a loyalty program which encourages customer retention.
Loyalty Program Badge	The DMO for the different badges that program members can win and be assigned as rewards.
Loyalty Program Currency	This DMO refers to the currency data that the loyalty program uses.
Loyalty Program Engagement Attribute	This DMO includes data about certain attributes that the owner of the loyalty program can define for tracking customers's loyalty. Some examples coudl be: X number of times log in, time on site, etc.
Loyalty Pgm Engmt Attribute Promotion	This DMO is used for the different promotions that are associated with the Loyalty Program Engagement Attributes available.
Loyalty Pgm Group Member Relationship	This DMO contains info about a loyalty program member and the contribution they mean to a group of the program they're part of.
Loyalty Program Member	This is the core DMO which refers to a person or individual who has joined the loyalty program.
Loyalty Program Member Attribute Value	The DMO used for tracking the specific value that a program member has obtained in relation to an Engagement Attribute goal.
Loyalty Program Member Badge	This DMO includes the badges that a loyalty program member has been given.
Loyalty Program Member Case	This is the DMO which contains the cases opened or created by a loyalty program member.
Loyalty Program Member Promotion	This DMO contains the data and details about the promotions available to a specific program member.
Loyalty Program Partner	The DMO for companies that have loyalty program offerings for members.
Loyalty Tier	This DMO defines the tier within the loyalty program where the benefits increase to higher levels for members.
Loyalty Tier Benefit	This is the DMO which contains the specific benefits available within a particular Loyalty Tier.
Loyalty Tier Group	This DMO refers to those loyalty programs with multiple sets of benefits that are grouped based on business goals or clusters. E.g: lifetime.
Loyalty Transaction Journal	This DMO is used to track the activities, changes, adjustments and behaviours of members in a loyalty transaction.
Market Segment	This is a DMO for Segments in Salesforce Data Cloud. Segments are the audiences of different promotions which sahre specific segmentation criteria.
Member Benefit	This DMO refers to a specific benefit in the loyalty program which a loyalty program member has decided to obtain being qualified for it.
Product	This is the Data Cloud DMO for products available in a company.
Product Category	The DMO for the Product Categories of those products available for sale in a company.
Promotion	This DMO contains the info about promotions associated to a loyalty program. E.g: type of promotion, promotion status, etc.
Promotion Loyalty Partner Product	This is the DMO for the product which one of the program partners co-markets to loyalty program members.
Promotion Market Segment	This is a DMO for those promotions that are associated to a specific market segment.
Unit of Measure	This is a Data Cloud DMO which is used for defining units of measure of the units or quantity of products purchased by loyalty program members.
Voucher	This DMO contains details about voucher definitions assigned to a loyalty program.
Voucher Definition	This DMO contains the data about voucher defintions assigned to a loyalty program, such as expiration date.

Subject Area – Party Data Model

The Party Subject Area is one of those tricky groups of the Salesforce 360 Customer Data Model, so I feel it deserves further initial clarification.

The term “party” can refer to the following elements:

Search:

Term	Description	Purpose
Party Subject Area	The Party Subject Area is a group of the Customer 360 Data Model that includes DMOs related to data about a Contact.	The purpose of Subject Areas is to group together DMOs that are related to the business area in the SF Canonical Data Model.
Party Identification DMO	A Data Model Object (DMO) of the Data Cloud Customer 360 Data Model that contains data about a contact and its different identifiers and unique numbers. E.g: a driver's license as a Party Identification of a specific Contact.	It helps identify all the different "contexts" in which a Contact has an identification and a number assigned to that identification in that context. E.g: - David as a driver with his license number
Party Identification ID	An Attribute or field in the Data Model Object (DMO) Party Identification.	The Party Identification ID attribute in the Party Identification DMO is the Primary Key. It is used to uniquely identify a contact. For example, in the context of Driver's Licenses, David's driving license has a unique ID as Primary Key of that row.
Party	An Attribute or field in the Data Model Object (DMO) Party Identification.	This Party attribute is the reference ID to the parent Party, that is, the Individual of all those party "contexts/scenarios". This ID is the same as the one in Individual. E.g: David (Individual) is the parent Party of David as a driver with driver's license XXX.
Party Identification Type	This is an attribute of the Party Identification DMO. It is the specific type of identification. It is optional in match rules configuration.	Some types could be, for instance: - License - Loyalty Membership
Identification Name	This is an attribute of the Party Identification DMO. It is the name of the specific identification. This attribute is mandatory in match rules configuration.	Some names could be: - State Driver License - Airline Member Number
Identification Number	This is an attribute of the Party Identification DMO. It is the actual value of the identification record, used in Identity Resolution to match customer profiles.	An example of an Identification Number for a Driver License could be like: 000723-F

EXAMPLE
Think of the Party Identification DMO as an object that collects all the “versions/scenarios” of a an Individual where an ID is needed and assigned to that Individual in those contexts.

The relationship is 1:N
1 Individual can have –> N Party Identification records

For example, David Palencia is x1 Individual, but he also exists in lots of “scenarios” where an ID is assigned to him:

– David as a driver with license number XXXXX01
– David as a registered citizen with ID XXXXX02.
– David as a child registered in birth certificate with ID XXXX03 in family documents.

x1 David –> 3 Party Identification records

Having said that, here is the breakdown of the Party Data Model and its DMOs grouped in the Party Subject Area:

Search:

Data Model Object (DMO)	Description
Account	This DMO has the info of how a party wants to interact with your company.
Account Contact	The DMO for the Individual within an Account with a specific role in that Account.
Contact Point Address	This DMO contains the mailing address of a party.
Contact Point App	The DMO with the info about the software application used by a Party on a specific Device.
Contact Point Email	The DMO for the email address of a specific party.
Contact Point Phone	The DMO for the phone number of a specific party.
Contact Point Social	The DMO for storing the social media information about a party.
Individual	This is the Data Cloud DMO for all the people who interact with your company.
Lead	This is the Data Cloud DMO for all the people who has shown interest in your company's services or products.
Party Identification	The Data Cloud DMO used for storing all the ways or contexts where an Individual is considered an identified Party. E.g: a driver's license.

Subject Area – Privacy Data Model

If the Party Subject Area seems rather confusing, the Privacy Data Model takes this complexity to a whole new level: it has its own Privacy Data Model.

Since this area of the data model is the foundation of your company’s consent management and data privacy preferences, I’ll devote a whole section to this model further down.

As a high level overview for now, these are the primary DMOs in this Subject Area:

Search:

Data Model Object (DMO)	Description
Authorization Form Consent	This DMO contains all the details of a form which gathered consent, with the following info: where, when, how, what policy, etc.
Communication Subscription	The DMO for the subscription preferences of a customer for a specific communication.
Communication Subscription Consent	This DMO contains the engagement or channel preferences of a specific customer.
Contact Point Consent	The DMO with the consent preference info of a customer for a given contact point. E.g: consent preferences for email.
Engagement Channel Type Consent	The DMO that contains individual preferences of privacy in a specific channel of communication, such as email or SMS.
Party Consent	This DMO stores the consent preferences of an Individual.

Subject Area – Product Data Model

This Subject Area groups together all the DMOs related to anything your company sells or uses as part of a product to track service purposes.

These are the DMOs in this area:

Data Model Object (DMO)	Description
Brand	This DMO stores the brand of a product.
Goods Product	This DMO stores the data about a specific product.

Search:

Data Model Object (DMO)	Description
Product Catalog	This DMO stores the inventory of your company.
Product Catalog Category	This DMO stores the category of the product catalog. E.g: sports.
Product Category	This DMO includes info about the categories of products or services that a company sells. E.g: tennis equipment.
Product Category Product	This DMO is used for identifying how products are assigned to Product Categories. E.g: for a certain company, a tennis outfit could be categorised as both "tennis equipment" and "sportswear".

Subject Area – Sales Order Data Model

The Sales Order Subject Area of the data model includes all the information about the future revenue or quantity of an Opportunity. It also includes product families, territory or hierarchy in organising this information.

These are the DMOs included in this data model:

Search:

Data Model Object (DMO)	Description
Sales Order	This DMO stores the data about outstanding and current sales orders in your company.
Sales Order Product	This DMO stores the specific product. E.g: a smartphone, a book.
Sales Store	This DMO includes info about a retail store which sells the products.
Order Delivery Method	This DMO is used for identifying the order and delivery method selected.
Opportunity	This is a core DMO that stores a sale or business deal which is in progress and is not completed yet.
Opportunity Product	This is the DMO which contains the product that the Opportunity represents. It serves a N:N relationship.

Additional Standard Data Model Objects

There are other Standard Salesforce Objects which are included in the Customer 360 Data Model. These can help in data modelling as well.

Search:

Data Model Object (DMO)	Description
Market Journey Activity	This is the DMO for a specific Journey Builder step or Activity in SFMC Journey Builder.
Market Segment	This DMO stores an audience or segment, which is a group of people who share the same segmentation criteria (e.g: demographics, behaviour, etc).

Search:

Data Model Object (DMO)	Description
Software Application	This is a Salesforce Data Cloud DMO used for having info about programs that your company made for its end users. E.g: an app for your VIP club of consumers

Salesforce Privacy Data Model

The Privacy Model in the Salesforce 360 Customer Data Model is the foundation of consent management and privacy preferences for your company and customers.

It is flexible and robust, capable of addressing every single aspect of consent management for any customer scenario.

First, you need to know that:

the consent model is related to the Individual DMO as the foundation for any consent. The relationship is 1:N (one Individual will have many consent preferences stored).

An Individual is just a parent abstraction of any person object, such as Lead, Contact, User, Person Account, etc.

Second, the Privacy Data Model allows you to manage consent on different levels or layers for the Individual object:

Global Consent
Engagement Channel Consent
Contact Point Consent
Data Use Purpose
Brand

Global Consent refers to the global consent settings for an Individual: a customer giving you general consent or not at all. This manages the general privacy settings.

Global Privacy Settings:

Search:

Global Consent Setting	Description
Don't Process	do not collect, share, store, etc my personal data.
Don't Profile	do not use my consent for profiling, creating personas, segmentation, etc.
Don't Solicit	preference not to solicit products or services.
Don't Track	do not track my web activity, if I open an email, etc.
Forget This Individual	delete all my records and personal data related to my Individual.
OK to Store PII Data Elsewhere	consent to store Personally Identifiable Information outside the legislation area. E.g: store my EU's personal data in the UK.
Individual's Age	an indication of whether an Individual is a minor.
Block Geolocation Tracking	do not track my geolocation on mobile devices.

EXAMPLE
One of your customers, the Individual Jane Doe, has given global consent to your company, but with the following global settings in her Individual record:

OK to Store PII Data Elsewhere –> YES
Block Geolocation Tracking –> YES
Don’t Profile –> YES

Jane is saying “Ok, I give you my consent, but with these global preferences”.

Engagement Channel Consent is managed with the ContactPointTypeConsent object, and it refers to consent preferences for a specific contact point or channel of communications.

Contact Point = a point of contact or channel format between the company and the customer (Individual).
E.g: email or phone.

Search:

DMO	Description
Engagement Channel Type	This is the Data Cloud DMO for the channels supported by individual preferences. For example, I give you consent for email communications but not for phone calls.

EXAMPLE
Your customer Jane Doe, after giving you her global consent and privacy settings, manages her preferences on the specific Contact Point Types she wants:

Email –> YES
Phone –> NO
SMS –> NO

Jane is saying “Ok, I give you my general consent, but you can only contact me by email, not by phone or SMS”.

This level refers to, within a Contact Point Type or channel (e.g: email), the specific contact point on which the customer wants to be contacted.

For example, a customer may give consent for email channel (Level 2), but only on a personal email address john@example.com, not on the work email address johnatwork@work.com (Level 3).

EXAMPLE
Jane Doe has given your company her global consent (Level 1) and channel consent for only email communications (level 2), and now manages her preferences regarding the email channel:

Personal Email jane@personal.com –> YES
Work Email jane@work.com –> NO

Jane is saying “You have my consent and you may contact me via email (not SMS or Phone), but for email, only on my personal email address”.

Level 4 – Data Use Purpose

This level is closely related to Levels 2 and 3. It defines the data purpose of the consent given on a specific channel and contact point. What is the reason for the company communications?

Some examples:

Is it transactional communications, which are a legitimate interest related to the service the company gives? (e.g: an Order Confirmation email)
Is it commercial communications with a promotional purpose? (e.g: marketing campaigns, new products).

In other words, within a Level 2 and Level 3 consent (specific channel and specific contact point), your company may have different data purposes: newsletters, social media, profiling, etc.

This object manages that.

EXAMPLE
Jane Doe wants you to contact her by email, and specifically, only on her personal email address. Yet, she only wants to be contacted for Service-related communications, so this means:

Transactional messages related to the service –> YES
Newsletters, promotions, marketing purposes –> NO

Jane is saying “You can reach out to me by email and only on my personal email address, but only for this specific reason”.

Brand

Brand is not part of the Privacy Data Model, but it’s an important part of it as a related object.

The object that manages this aspect is BusinessBrand, which has a native relationship with the objects Contact Point Type and Contact Point Consent. It defines for what Brand within your Org the consent applies.

E.g: you may have Levels 1, 2, 3 and 4 for managing consent, but these can differ across multiple company brands within the same Salesforce Org.

EXAMPLE
Jane Doe wants you to contact her by email, only on her personal email address and only for transactional, service related communications. However:

Transactional messages related to the service for Brand A –> YES
Transactional messages related to the service for Brand B –> NO

Jane is saying “I told you how you can contact me and on which address and for what reason, but only for Brand A comms within your company brands”.

All the Data Subject Rights Requests that you receive from customers need to be processed using the Consent API in Data Cloud.

The Data Cloud Consent API reads and writes to the Profile of a customer (Individual, Contact, Lead, User, Person Account object records) in Data Cloud. It does so by accessing and updating org-wide consent data (e.g: links between records, values of consent flags, etc).

These are the actions supported by the Consent API, as documented by Salesforce:

Search:

Action	Description
ShouldForget	This is the Right To Be Forgotten: permanently deleting PII (Personally Identifiable Information) data and all related records.
Processing	This action restricts the use of Data Cloud processes (e.g: insights, query, segmentations) to process the customer data.
Portability	This is used to allow the customer to have thier Data Cloud data exported.

DOCUMENTATION:
– Check the following link for the official Developer documentation of the Consent API:
https://developer.salesforce.com/docs/atlas.en-us.250.0.api_rest.meta/api_rest/resources_consent_cdp_params.htm

DATA DELETION REQUESTS
– A Data Deletion Request (processed by the Consent API) deletes the Individual entity and all the entities where you have configured a relationship between the entities’ Primary Key and the Individual ID attribute in the Individual DMO.
– If you store customer data in any entities that aren’t mapped to the Individual Entity, the Consent API will not remove that data.
– Data Deletion Requests are processed again after 30, 60 and 90 days to make sure a full deletion has been done. You will have to submit Data Deletion Requests separately for each connected Salesforce Cloud.

Data Cloud Privacy Model DMOs

Here is a comprehensive list of all the Data Model Objects (DMOs) that are included within the Privacy Data Model in the Salesforce 360 Customer Data Model:
General

Search:

Data Model Object (DMO)	Description
Authorization Form Consent	This DMO contains all the details of a form which gathered consent, with the following info: where, when, how, what policy, etc.
Communication Subscription	The DMO for the subscription preferences of a customer for a specific communication.
Communication Subscription Consent	This DMO contains the engagement or channel preferences of a specific customer.
Contact Point Consent	The DMO with the consent preference info of a customer for a given contact point. E.g: consent preferences for email.
Engagement Channel Type Consent	The DMO that contains individual preferences of privacy in a specific channel of communication, such as email or SMS.
Party Consent	This DMO stores the consent preferences of an Individual.

Contact Consent Configuration

Search:

DMO	Description
Authorization Form	The DMO for the group of privacy policy, contract, terms and conditions or consent forms.
Authorization Form Data Use	This DMO stores the data uses within an authorization form.
Authorization Form Text	The Data Cloud DMO for storing the language and text of a specific consent form (authorization form).
Communication Subscription Timing	This is the DMO that stores the Individual's preferences for timing of receiving communications.
Data Use Purpose Consent Action	This DMO stores the Individual's consent preferences for consent actions, such as data collection, tracking, sharing, etc.

Contact Consent Setup

Search:

DMO	Description
Communication Subscription Channel Type	This is the DMO that stores info about a specific engagement channel. E.g: email, SMS.
Consent Action	This DMO stores the uses for which the Individual consents to give their data (e.g: tracking, sharing).
Consent Status	This DMO stores the consent status: opted in, opt out.
Data Use Legal Basis	This the Data Cloud DMO that contains the info about the legal reason why the company communicates with the Individual. E.g: billing, contract.
Data Use Purpose	This is the DMO that stores the data use purpose of the communications. E.g: transactional, marketing communications, etc.

Engagement

Search:

DMO	Description
Engagement Channel Type	This is the Data Cloud DMO for the channels supported by individual preferences. For example, I give you consent for email communications but not for phone calls.

Salesforce Data Cloud Primary Keys

One of the key aspects of how Data Cloud uses data is the concept of Primary Keys and Data Lineage.

Let’s look at some important terminology first:

Search:

Term	Description	Example
Primary Key	This is the Data Source Field that uniquely identifies a row or record in a table.	In an Order object, the Primary Key could be OrderID. E.g: OrderID = 001 OrderID = 002 Each unique Order has an ID value that is different per row.
Composite Key	When a Data Source does not have a single field that uniquely identifies a record, you can combine multiple fields (usually through Concatenation) to create a new, extra field, out of a Formula. This is a Composite Key.	If OrderID was not enough to uniquely identify one row, we could come up with the following unique combination of both orderID and SKU of a product. E.g: OrderID_SKU 001_DKL
Key Qualifier	When multiple Data Sources have duplicated values in the Primary Key field, a Key Qualifier is an extra field that helps you identify where the data comes from, to deduplicate. A Key Qualifier is the Source of the data, for example.	If your company has Contacts from both CRM and SFMC in 2 different Data Sources, the Key Qualifier "Source" could be added to distinguish and keep Data Lineage: ContactID = 001 Name = David Source = SFMC ContactID = 001 Name = David Source = CRM
Fully Qualified Key	A Fully Qualified Key is the combination of having the Data Source Primary Key Field + Key Qualifier Field. We talk of Fully Qualified Keys when the data lineage and record uniqueness can be tracked thanks to the added Key Qualifier field.	Once we use the "Source" field to identify where data comes from, we can uniquely identify records with the same source Primary Key value. ContactID = 001 Source = CRM ContactID = 001 Source = SFMC ContactID = 002 Source = SFMC

DLO Primary Key != DMO Primary Key

This is a very common scenario.

Let’s imagine you want to ingest Customer Data into Data Cloud, and you have the following 2 DLOs with 1 row and 2 rows, respectively:

DLO 1
CustomerID (PK) = 001
Name = Laia

DLO 2
ID (PK) = 001
Name = Laia

ID (PK) = 002
Name: Alex

Now, let’s imagine a simplified version of the Individual DMO with these attributes and Primary Key:

Individual DMO
Individual Id (PK)
Name

Based on the Primary Key fields and values of the DLOs, if we map these 2 DLOs to the DMO, we would get…2 rows right? Both Laias share the same value for the Primary Keys of the DLOs (001):

Individual Id = 001 (Laia)
Individual Id = 002 (Alex)

However, this is not how Data Cloud works.

The Individual DMO, although it has Individual Id as the Primary Key, it will be mapped with these 3 rows instead:

Individual Id = 001 (Laia)
Individual Id = 001 (Laia)
Individual Id = 002 (Alex)

DUPLICATE VALUES IN PRIMARY KEY
This scenario will lead to duplicate values in the Primary Key field in the mapped DMO. This is expected behaviour, as Data Cloud is intended to have a CDP functionality.

In other words, it needs to ingest all the possible versions of each customer (even if there are duplicates) so that later on, it can unify them during Identity Resolution.

Using Fully Qualified Keys solves this issue, as it will be explained below.

Key Qualifiers and Fully Qualified Keys

How do we solve the issue of having duplicated Primary Key values?

Using Key Qualifiers to have Fully Qualified Keys in the DLOs.

For example, consider these 2 rows in the Individual DMO:

Individual DMO
Individual Id = 003
KQ_ID = CRM

Individual Id = 003
KQ_ID = SFMC

By adding the extra Source field as a Key Qualifier (KQ_ID), we now have an extra attribute to uniquely identify records.

USE KQ IN QUERIES AND SEGMENTATION
Once your DMOs have Fully Qualified Keys, you can use JOINs in SQL Queries, segment, perform insights, etc using the extra Source field so that you don’t create duplicated results.

For instance:
Run a Query to retrieve “unique Individuals who purchased X product”.

Using the Key Qualifier in your JOIN will only select unique records, so if you have Individual Id = 003 in 5 duplicate rows but only the SFMC one purchased, the query will return 1 result.

– Check this documentation link for further information on Key Qualifiers:
https://help.salesforce.com/s/articleView?id=sf.c360_a_data_inter_fqk.htm&type=5

How to configure and use Fully Qualified Keys

When you configure multiple Data Lake Objects (DLOs) to be mapped to the same DMO, you need to ensure that all of the DLOs have the Key Qualifier field.
You need to add the Key Qualifier Field after configuring the Data Stream for the DLO.
Data Cloud automatically creates the Key Qualifier fields in DMOs after they have been configured in the corresponding DLOs.
In Tableau, Calculated Insights, all SQL table joins, dimensions, etc, always use Key Qualifier fields to ensure data is accurate.

DOCUMENTATION
– Fully Qualified Keys:
https://help.salesforce.com/s/articleView?id=sf.c360_a_fully_qualified_keys.htm&type=5
– Primary Keys:
https://help.salesforce.com/s/articleView?id=sf.c360_a_primary_key.htm&type=5

Salesforce Data Model Mapping

Before you start the Data Model Mapping implementation, let’s do a quick recap of previous steps:

Design: Data Strategy and Discovery
Plan a thorough Data Strategy and Discovery phase so you can create a detailed Data Inventory of all your source data, mappings, PKs, schemas, Data Model extensions, etc.
Salesforce Data Cloud Data Model is normalised.
Your source data will need to be normalised before it can be mapped.
Assess Transformations and Mappings
Decide how to leverage Data Model Subject Areas, how you will transform data when necessary, etc.
Select Data Object Type Categories
Profile, Engagement, Other.
Remember that once the first DLO is mapped to a DMO, the Data Model Object will inherit, keep and only allow that Data Object Type Category in the future.

Now, let’s look at the actual mapping workflow in Data Cloud.

Data Cloud Objects

Here’s a recap of the different types of objects that exist in Salesforce Data Cloud and how each of them is created on a different stage of the data process:

Search:

Name	Term	Stage	Format	Purpose	Location
Data Source Object	DSO	Stage 1: raw, when data source is first ingested and a Data Stream is configured	- Multi Format (e.g: CSV, Json, etc). - Original schema is preserved - Multi sourced: Mulesoft, Cloud Storage, etc.	Original data source and files/transient data of the organization. Needed so a Data Lake copy can be created for later mapping.	Not physically stored: A staging or temporary view of the original, raw data, before it's created physically in the Data Lake as a DLO.
Data Lake Object	DLO	Stage 2: automatically created as a locally stored copy of the DSO, but including transformations, validation, normalisation, etc.	- Schema is enforced. - Categorised into DC types of objects: Profile, Engagement, Other - Parquet Formatted Iceberg tables	Normalised, validated and transformed version of the DSO so it can be mapped to the SF Data Model. Objects cannot be used unless they're mapped to the Data Model.	Physically stored in the Data Lake assigned Data Space: This is the core "copy" of the data ingested. Data only exists at the DLO level in Data Cloud.
Data Model Object	DMO	Stage 3: DLOs are mapped to a SF 360 Data Model object and this creates a harmonized grouping of data that is mapped to the canonical DM of Salesforce.	- Harmonized and grouped view of the DLO, mapped to a data model object. - Type Category is inherited from the DLO mapped. - Unified Individuals and Insights are DMOs.	Mapped version of the DLO so it can be leveraged in Data Cloud features: insights, segments, identity resolution, etc.	Not physically stored: A DMO is just a "view" of the DLO in the Data Lake, not a copy of the DLO itself. It is not materialised.

How to map Data Model Objects

Go to the Data Streams tab in Data Cloud
Find the Data Stream you want to map
Click on Start Data Mapping OR Review if mappings have already been configured
Click on Select Objects to display the available DLOs
Select the Field to map from DLO and click on the target DMO Related Field

CUSTOM OBJECTS AND FIELDS
– If the DLO field you’re mapping doesn’t have an equivalent in the target DMO, you can click on Add New Field next to the “Unmapped fields” icon.
– If you need to create Custom Objects in your Data Model, Data Cloud lets you do so by clicking on New Custom Objects when you’re first selecting what objects to map.

DMO Data Object Type Categories

DMOs come without an assigned Data Object Type Category (Profile vs Engagement vs Other).

The DMO will inherit the Object Type Category of the first DLO that you map to it.
Once the first DLO is mapped, the DMO will keep and only allow mappings of the same Object Type Category.

INDIVIDUAL DMO
The Individual DMO is an exception and will always come with a pre-defined Object Type Category = Profile.

1 DLO <–> 1 DMO Mapping

When mapping, take into account these 1 DLO <–> 1 DMO requirements and best practices:

You can only map 1 DLO Attribute –> to 1 DMO Attribute.
E.g:
You cannot map both:
DLO.PrimaryEmail –> DMO.EmailAddress
DLO.SecondaryEmail –> DMO.EmailAddress
You can map 1 DLO Attribute –> to +2 different DMO Attributes.
E.g:
DLO.PrimaryEmail –> DMO.EmailAddress
DLO.PrimaryEmail –> DMO.AlternativeEmail
If you want to map +2 DLO Attributes to the same DMO Attribute, you could, for example, separate data so that there are 2 Data Streams and DLOs mapped to the same DMO.

N DLOs <–> 1 DMO Mapping

Data Cloud allows you to map several Data Lake Objects (DLOs) to the same target Data Model Object (DMO).

Here are some best practices:

Use multiple DLOs to 1 DMO if you have several Data Sources from different systems and they all align well with the same DMO.
E.g:
Ecommerce_Orders
StoreOrdersThey are two different data sources, but both contain information of the same data model entity.
It’s possible that each Data Source aligns well with different target attributes in the same DMO.
E.g:
Ecommerce_Orders has the needed attributes for OrderId and Currency
StoreOrders has other attributes that Ecommerce_Orders lacks, so they complement each other.
It’s also possible that both Data Sources have attributes that map to the same target attribute in the DMO.
E.g:
Ecommerce_Orders.OrderID –> DMO.ID
StoreOrders.OrderIdNumber –> DMO.ID

Data Bundles automatic mapping

During Data Cloud Data Ingestion, Data Bundles allow you to ingest and map pre-defined objects from popular Salesforce Clouds (e.g: Service and Sales Cloud, Salesforce Marketing Cloud, etc).

These Data Bundles automatically map the Salesforce standard objects to the Data Cloud DMOs.

You can review the Data Streams after the Data Bundle is configured and deployed.

Configure Object Relationships

To review and/or configure DMO Relationships:

Click on Data Model tab in Data Cloud
Select your DMO
Click on Relationships tab

In terms of the Data Relationships that you can configure for DMOs, there are 2 types:

Standard Data Relationships
The standard data relationship is a built-in relationship. It’s enabled once there is at least one mapping between the related DMOs. You may disable standard relationships but you cannot delete them.
Custom Data Relationships
You may create custom data relationships between DMOs on the Relationships tab. You may also delete or deactivate a custom data relationship. A custom data relationship is deleted automatically when the mapping for at least one field is removed.

Data Relationships always come in the following format:

Search:

Object	Field	Key Qualifier (Field)	Cardinality	Related Object	Related Field	Key Qualifier (Related Field)
Case	Account Contact	KQ_AccountContactId	N:1	Individual	Individual Id	KQ_Id

There are 2 levels where you can configure Data Relationships:

At the Data Source level
You may configure data relationships for your Data Sources.
For example, OrderLineItems might have a N:1 relationship with Order (e.g: one OrderID can have multiple OrderLineItems)
At the Data Model Object level
Individual DMO has a 1:N relationship with Contact Point Email (e.g: one Individual may have multiple email addresses to be contacted on).

DATA RELATIONSHIPS BEST PRACTICES
– Data Cloud allows you to set up multiple Data Relationships for the same Data Model Object (DMO).
– Data Cloud only allows 1 Data Relationship per pair of fields of two mapped DMOs.
– Data Relationships have “Status” that can be Activated or Deactivated. Data Relationships that are used in Segmentation, Activation, etc cannot be deactivated unless they are removed from those. Also, the Data Relationships that are used in Identity Resolution must be always Active and cannot be deactivated.

Data Types in DLO and DMO

The data types in the fields mapped between a Data Lake Object (DLO) and a Data Model Object (DMO) must be compatible. Otherwise, Data Cloud will not let you map them.

Use this table for reference of compatible data types:

Search:

Field Type in DLO	Compatible Field Types in DMO
Text	Text, Email, Phone, URL
URL	URL, Email, Phone, Text
Number	Number, Text
Phone	Phone, Email, Text, URL
Percent	Percent, Number
Boolean	Boolean
Email	Email, Phone, Text, URL
Date	Date
DateTime	DateTime

Required Data Model Mappings and Relationships

These are the DMOs that you must map for Data Cloud to work in terms of Identity Resolution, Activation, etc:

Individual
Party Identification
Contact Point Address
Contact Point Email
Contact Point Phone
Contact Point App
Contact Point Social

Find below a table with the Data Model Data Object Relationships for the required mandatory DMOs:

Search:

Object	Field	Cardinality	Related Object	Related Field
Individual	Individual Id	1:N	Party Identification	Party
Individual	Individual Id	1:N	Contact Point Address	Party
Individual	Individual Id	1:N	Contact Point Phone	Party
Individual	Individual Id	1:N	Contact Point Email	Party
Individual	Individual Id	1:N	Contact Point App	Party
Individual	Individual Id	1:N	Contact Point Social	Party

Data Model Dependencies

You may run into technical issues that stem from what’s often called by Salesforce, Data Model “interlocking”.

Once there are dependencies configured for a specific DMO, this Data Model Object will require at least 1 DLO actively mapped to it.

This means that you cannot delete records from a Data Stream, for example, unless you remove those DMO dependencies.

What are these DMO “interlocking” dependencies?

The DMO is used in Identity Resolution
The DMO is used in Insights
The DMO is currently used in Segmentation
The DMO is being used for Activations

EXAMPLE
Your Data Use Purpose DMO is actively used and configured in the following dependencies:
– Segmentation
– Insights
You want to remove the Data Stream that ingests source data into the Data Use Purpose DMO, but the system won’t allow you. You would need to first remove the DMO from the Segmentations and Activations so that you can then delete the Data Stream.

Recap and Summary

This would be the logical order of steps when implementing Data Mapping in Data Cloud:

Perform a thorough and strategic Data Design phase (e.g: data inventory, strategy and planning, schemas and Primary Keys, Use cases, etc).
Get familiar with the Salesforce 360 Customer Data Model, Subject Areas, etc.
Plan how your company will leverage the Privacy Data Model for consent management.
Go through Data Model Mapping, taking into account:
– Data Object Type Categories
– DLO x DMO mapping best practices
– Object Relationships
– Data Type Compatibility
– Required DMO mappings
Take into account dependencies and interlocking once the model is mapped

Salesforce Data Cloud Activation

Salesforce Data Cloud Segmentation

Salesforce Data Cloud Insights

Salesforce Data Cloud Data Modelling

Data Mapping and the Salesforce Customer 360 Data Model

Data Mapping

Salesforce Customer 360 Data Model – Overview

Canonical Data Model vs BYO Data Model

Data Modelling Phases

Data Design

Data Build

Customer 360 Data Model – Subject Areas

Subject Area – Case Data Model

Subject Area – Engagement Data Model

Subject Area – Loyalty Data Model

Subject Area – Party Data Model

Subject Area – Privacy Data Model

Subject Area – Product Data Model

Subject Area – Sales Order Data Model

Additional Standard Data Model Objects

Salesforce Privacy Data Model

Level 1 – Global Consent

Level 2 – Engagement Channel Consent

Level 3 – Contact Point Consent

Level 4 – Data Use Purpose

Brand

Data Cloud Consent API and Data Subject Rights

Data Cloud Privacy Model DMOs

Salesforce Data Cloud Primary Keys

DLO Primary Key != DMO Primary Key

Key Qualifiers and Fully Qualified Keys

How to configure and use Fully Qualified Keys

Salesforce Data Model Mapping

Data Cloud Objects

How to map Data Model Objects

DMO Data Object Type Categories

1 DLO <–> 1 DMO Mapping

N DLOs <–> 1 DMO Mapping

Data Bundles automatic mapping

Configure Object Relationships

Data Types in DLO and DMO

Required Data Model Mappings and Relationships

Data Model Dependencies

Recap and Summary