Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

Map Required Objects

Learning Objectives

After completing this unit, you’ll be able to:

  • Recognize Customer 360 Data Model components.
  • Describe individual, contact point, and party objects.
  • Identify mapping requirements for identity resolution rulesets.

Customer 360 Data Model Components

To understand requirements for data and identity concepts further, we need to review the Customer 360 Data Model. The Customer 360 Data Model is Data Cloud's standard data model that helps with the interoperability of data. Which is a fancy way of saying it makes data usable wherever you need it. Understanding Customer 360 Data Model components can make it easier when you go to map data and create identity resolutions rulesets. Let’s review.

subject area diagram

Subject Area (A Business Goal)

The Customer 360 Data Model groups subject areas or data models according to business goals. Those goals could be to market or promote your product or provide seamless product support to your customers. Data model subject areas might include a grouping of unique identifiers called party, or could be engagement data, sales orders, or product information. 

Data Model Object, also called DMOs (Groups of Data)

An object in the data model created by ingested data streams and insights. DMOs can be standard or can be custom, based on your business needs. A DMO stores data such as leads, product info, customer info, and so on. 

Attributes (Data About Your Contacts)

Attributes are the unique bits of information you know about a given contact, from a variety of different sources. These pieces of data help you link an individual’s data together and ultimately build a unified profile of the customer. For marketers, these data points are marketing gold because they can be used to create fine-tuned segments. For example, you might want to send a coupon to all contacts under the age of 25 who prefer weight lifting to running. To do so, you need age and activity preference data in your Data Cloud. 

Note

There are standard attributes already created for you to use, however your organization can also create custom attributes based on your business use case.

The Importance of Data Mapping

Now that you have had a refresher, it’s time to get serious. In order to create unified profiles, you must map your data correctly. Data Cloud is like artificial intelligence (AI) because it requires quality data and some human intervention to be most effective. 

With Data Cloud, the system can only unify profiles if they are mapped correctly to the individual object and one other element: a contact point object or a party identifier object

Let's start with the first required option, the individual object.

Individual Object

The individual object is the most important because it has all the personal information you know about your customer. And that data can come from all types of sources (from commerce data to social media posts). In fact each data stream that is added needs to have one field that connects to the individual ID field in order to create a unified individual profile. It is required for identity resolution. 

Let’s repeat that one more time for emphasis. 

All data streams with customer information need to have a field mapped to the individual ID field from the individual object in order to use identity resolution. 

Required Mappings and Relationships

In our example using the NTO Loyalty program data source, the field mapped to individual ID is the SubscriberKey field. The individual ID is the most important attribute for identity resolution rulesets. It serves as the primary key for the individual object and is required for mapping and identity resolution. In your datastream, whatever field is the unique identifier for that customer should be mapped to this ID. Here are the specific mapping requirements and options for the individual object.

Data Model Object 

Attributes

API Names

Map To

Individual

  • Individual ID (primary key)
  • First Name
  • Last Name
  • ssot__Id__c
  • ssot__FirstName__c
  • ssot__LastName__c
  • Individual.ID → ContactPointAddress.Party
  • Individual.ID → ContactPointApp.Party
  • Individual.ID → ContactPointEmail.Party
  • Individual.ID → ContactPointPhone.Party
  • Individual.ID → PartyIdentificationId.Party

You can also map any additional fields from your customer data to the standard and custom attributes associated with the individual object. For example, map information like birth date, first name, last name, and so on. 

Not only do you need to map all customer data to the individual ID field, you must also map your data to one other object. Let's review your options.

Contact Point Objects

Contact points (things like email, phone, address, device, and social) all have associated objects that can be used for identity resolution. This information represents specific information about a person that may change or be different in various systems. Similar to individual ID, a contact point ID serves as the primary key for the contact point object and is required for mapping and identity resolution. In your data stream, whatever field is the unique identifier for that customer, should be mapped to this ID.  Let’s review these object requirements. 

Data Model Object

Attributes

API Names

Map To

Contact Point Address

  • Contact Point Address Id (primary key)
  • Address Line 1
  • City
  • Party
  • Postal Code
  • State Province
  • ssot__Id__c
  • ssot__AddressLine1__c
  • ssot__CityId__c
  • ssot__PartyId__c
  • ssot__PostalCodeId__c
  • ssot__StateProvinceId__c
  • ContactPointAddress.Party → Individual.ID

Contact Point App

  • Contact Point App ID (primary key)
  • ssot__Id__c
  • ContactPointApp.Party → Individual.ID

Contact Point Email

  • Contact Point Email ID (primary key)
  • Email Address
  • Party
  • ssot__Id__c
  • ssot__EmailAddress__c
  • ssot__PartyId__c
  • ContactPointEmail.Party → Individual.ID

Contact Point Phone

  • Contact Point Phone ID (primary key)
  • Formatted E164 Phone Number
  • Party
  • ssot__Id__c
  • ssot__FormattedE164PhoneNumber__c
  • ssot__PartyId__c
  • ContactPointPhone.Party → Individual.ID

Party Identification Object

Last but not least is the party identification object. Party identifier matching allows you to use your own customer-supplied identifiers. Matching on a party identifier is especially important with Marketing Cloud Engagement data bundles. Data bundles include data sources that have subscriber-related data (like engagement metrics) that are associated with a subscriber ID AND data extensions that have customer information in them as well. If you decide to match based on party ID, there are other types of attributes that need to be mapped. 

For a list of current data bundles available for other Salesforce Clouds, visit the Starter Data Bundles documentation in the Data Cloud Reference Guide.

  • Party Identification ID: Similar to individual ID and contact point IDs, party identification ID is the primary key or the primary identifier from your customer data. It can be any unique ID.
  • Party: This ID is a foreign key that is the same as the one used in the individual object.
  • Party Identification Type: This is a required field for mapping but optional for identity resolution. This field provides additional information about the identifier, for example Social. Be descriptive, as it is used to set up your match rules.
  • Identification Number: The ID used for identity resolution comparison.
  • Identification Name: Similar to type, this required field is used to specify the name of the ID space—for example, Mobile ID or LinkedIn ID. This name is also used in match rule setup, so be descriptive.
  • Standard and custom attributes: Map any additional fields from your customer data to the standard and custom attributes associated with the party identifier.

Let’s see an example using a driver’s license as a unique identifier.

Party Identification ID

Party

Party Identification Type

Identification Number

Identification Name

100a

10016-00001

Driver License

D1469256

CA Driver ID

In summary, here are the required mappings for party identification.

Data Model Object

Attributes

API Names

Map To

Party Identification

  • Party Identification Id (primary key)
  • Identification Name
  • Identification Number
  • Party
  • Party Identification Type
  • SourceRecordId__c
  • ssot__Name__c
  • ssot__IdentificationNumber__c
  • ssot__PartyId__c
  • ssot__PartyIdentificationTypeId__c
  • PartyIdentificationId.Party → Individual.ID

Party Relationships

To enable unification across ID spaces, the party identification object has a relationship cardinality of Many To One, which simply means that you can have multiple party fields mapped to one individual object. In this example, there are 3 party identification types: one from LinkedIn, another called Contact ID, and a Marketing Cloud Subscriber Key. All three are possible and therefore the reason for the cardinality of Many to One. 

Exact party identification configuration, using LinkedIn, Contact ID, and MC Subscriber Key.

Since many systems use identifiers, you can easily add them to your matching rules after mapping and configuration. Just be sure to write down your types and names to make it easy for setup. 

Data Mapping Example

To help visualize this process, let’s review a data mapping example from Northern Trail Outfitters (NTO) data model. In this example, the data stream, NTO Loyalty Program (1), is mapped to the Individual object (2) and the Contact Point Phone object (3). NTO created this mapping in order to use phone numbers as a match rule. 

Mapping of Data source to contact point phone and individual.

Within this mapping, there are three required mappings (identified as primary keys). For this example, those primary keys are:

  • SubscriberKey
  • Contact Point Phone ID
  • Individual ID

Also notice that the SubscriberKey from the data source is mapped to the other primary keys and party. Why party? Because the party field helps provide a relationship between objects and primary keys found in data sources.

Note

Find data model object reference documentation on the Salesforce Developer page Model Data.

Next Up: Identity Resolution Rulesets

Now that you understand the importance of mapping, in the next unit we discuss the concept of identity resolution rulesets. 

Resources

Share your Trailhead feedback over on Salesforce Help.

We'd love to hear about your experience with Trailhead - you can now access the new feedback form anytime from the Salesforce Help site.

Learn More Continue to Share Feedback