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.

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.

Data Modelling Phases

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

1. Data Design
2. 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:

1. 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.
2. 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.

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:

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:

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:

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:

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

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:

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:

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:

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.

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:

1. Global Consent
2. Engagement Channel Consent
3. Contact Point Consent
4. Data Use Purpose
5. Brand

Level 1 – Global Consent

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:

Level 2 – Engagement Channel Consent

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.

Level 3 – Contact Point Consent

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).

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.

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.

Data Cloud Consent API and Data Subject Rights

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:

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

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:

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)

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.

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.

Salesforce Data Model Mapping

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

1. 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.
2. Salesforce Data Cloud Data Model is normalised.
   Your source data will need to be normalised before it can be mapped.
3. Assess Transformations and Mappings
   Decide how to leverage Data Model Subject Areas, how you will transform data when necessary, etc.
4. 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:

How to map Data Model Objects

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

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.

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:

1. Click on Data Model tab in Data Cloud
2. Select your DMO
3. 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:

There are 2 levels where you can configure Data Relationships:

1. 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)
2. 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 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:

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:

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

Recap and Summary

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

1. Perform a thorough and strategic Data Design phase (e.g: data inventory, strategy and planning, schemas and Primary Keys, Use cases, etc).
2. Get familiar with the Salesforce 360 Customer Data Model, Subject Areas, etc.
3. Plan how your company will leverage the Privacy Data Model for consent management.
4. 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
5. Take into account dependencies and interlocking once the model is mapped