Once you’ve configured Data Cloud, ingested data sources into it and mapped it to the Salesforce canonical data model, the next step is to configure Identity Resolution.
Identity Resolution means unifying all your ingested customer data so that you create a Single Source of Truth and Unified Profile for each one of your customers.
You might have dozens of customer versions coming from all the Data Lake Objects you set up. Duplicates.
Known customer profiles
Unknown customer data
Guest orders
etc
This unification process translates all of that customer data into:
- Unified Customer profiles
- Cross-device Identity Management
- Advanced Identity Resolution
- Deduplication.
Salesforce Data Cloud Identity Resolution
Identity Resolution Overview
The process flow of how Identity Resolution works goes like this:
1. Identity Sources –> 2. Identity Resolution –> 3. Unified Profile
Example:
- Your business has lots of source customer versions for one of your customers, Maria Gonzalez.
E.g:
#1 Maria Gonzalez’s social media profiles
#2 Maria Gonzalez as guest shopper on your ecommerce
#3 Maria as a Subscriber - Identity Resolution is executed, leveraging Data Cloud’s 2 main Identity Resolution features:
Matching Rules
Reconciliation Rules
This process finds and matches the different customer profiles of Maria. - Data Cloud gives your business a master Unified Profile of Maria Gonzalez, as a single source of truth that keeps all her source data lineage, contact points, etc.
E.g:
The Unified Profile keeps her marketing history, purchase history, invoices, devices, all her email addresses, etc.
Identity Resolution Source Matching
Let’s see how Identity Resolution identifies profiles with our example of Maria Gonzalez.
Imagine your business has 2 different systems that ingest source data of Maria into Data Cloud:
1) Marketing Cloud
2) Commerce Cloud
Marketing data
Subscriber #1
- Email: mariagonzalez@work.com
- Name: Maria Gonzalez
Subscriber #2
- Email: mariagonzalez@personal.com
- Name: Maria G
Commerce data
Order #1
- Ecommerce Account: mariagonzalez@personal.com
- Name: Maria Gonzalez
- Ecommerce email: mariagonzalez@personal.com
- Phone: +34 622589374
- Shipping Address: Calle del Rio, 18 30850, Murcia (Spain)
Order #2
- Ecommerce Account: Guest Checkout
- Name: Maria Gonzalez
- Ecommerce email: mariagonzalez@work.com
- Phone: 622589374
- Shipping Address: Avenida Cataluña, 164, 08023, Barcelona (Spain)
Total: 4 customer profiles of Maria. 2 Subscribers and 2 Ecommerce Orders.
Data Cloud has different ways of linking these profiles.
For example, for Ecommerce data, we can link Order #1 profile and Order #2 profile based on:
Normalised phone numbers:
Order #1 Phone: +34 622589374
Order #2 Phone: 622589374
AND using Name too:
Order #1 Name: Maria Gonzalez
Order #2 Name: Maria Gonzalez
In this example, the Identity Resolution Matching Rules applied would be:
Normalised Phone + Name.
Data Cloud would conclude, based on the Matching Rules, that these 2 profiles from 2 different orders, correspond to the same customer.
However, we could take it even further.
We could use Name Match + Exact Email as Matching Rules and conclude that one of the Marketing profiles is the same person as Order #2 profile too:
Subscriber #1
Email: mariagonzalez@work.com
Name: Maria Gonzalez
AND
Order #2
Name: Maria Gonzalez
Ecommerce email: mariagonzalez@work.com
And so on and so forth.
Once Data Cloud has identified and linked together all your source customer data profiles, a Unified Individual is created.
The resulting Unified Individual for our Maria Gonzalez example could be:
Unified ID: 5iu912xd-12cr-3482-4efr
Name: Maria Gonzalez
Telephone:
– International: +34 622589374
– Local: 622589374
Email:
mariagonzalez@personal.com
mariagonzalez@work.com
Order History:
Order #1
Order #2
Marketing Engagement History:
Opened Email 1
Received Email 2
Data Cloud Identity Resolution Terminology
Here’s a table with the most important terms used in the Data Cloud Identity Resolution process:
| Term | Description |
|---|---|
| Identity Resolution | The process whereby Data Cloud matches and reconciliates source customer profiles into a unified profile. |
| Identity Resolution Rulesets | A group of rules of 2 types: match rules and reconciliation rules. The Identity Resolution Ruleset is what is executed to process Identity Resolution. |
| Match Rules | One of the two types of rules within an Identity Resolution Ruleset. It can be, for example, Fuzzy Name or Exact Email. |
| Reconciliation Rules | When Data Cloud has multiple profiles for a Unified Profile, the Reconciliation Rules are configured to define what source profile the system should select (e.g: last updated). |
| Unified Profile | After Identity Resolution Rulesets apply, the Unified Profile contains all the source profiles of a customer, reconciliated into a single record and view of that customer. |
| Individual ID | This is the Unique Identifier of each customer profile, used by Data Cloud during Identity Resolution. It's the equivalent of, for instance, SubscriberKey in SFMC. |
| Party | Party can refer to a Subject Area of the 360 Data Model or the ID attribute in the DMO Party Identification. |
| 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. |
Please check the following link to see the official Salesforce documentation on Data Cloud Identity Resolution:
https://help.salesforce.com/s/articleView?id=sf.c360_a_identity_resolution.htm&type=5
Unified Profiles VS Golden Records
The term Golden Record is often discussed in conversations around Data Cloud and Customer Data Platforms (CDP).
Let’s look at what a Golden Record is and the differences between a Golden Record and a Unified Profile.
Firstly:
A Unified Profile != a Golden Record
Here are the differences:
| Record Type | Description | Example |
|---|---|---|
| Golden Record | A Golden Record is a static "winner" profile as "the best" one of all your source customer profiles. A Golden Record is desired because it simplifies profile unification. However, it has limitations: the same customer might prefer different email addresses for different purposes or at different times, and not one as "the best" email for all company communications. | Out of all the Maria Gonzalez customer profiles your company has, a Golden Record of Maria would select: - Best name: Maria Gonzalez - Best email address: mariagonzalez@personal.com - Best phone: +34 622589374 |
| Unified Profile | A Unified Profile adapts to real business scenarios, keeping all the data sources and lineage, having a complete view of each customer. It is dynamic so you can adapt to changing use cases, customer preferences, etc. | Instead of one single email, address, etc for our Maria Gonzalez example, the Data Cloud Unified Profile would keep all her data lineage and attributes: - All her email addresses - All her phones etc |
Data Cloud does create a Golden Record ID during Activation. Let’s use the previous example to show this. The steps in order are these:
1. Source customer profile (Source IDs)
–>
2. Unified Profile (Unified ID + Source IDs)
–>
3. Golden Record for Activation (Source ID as Golden Record ID)
We had 4 different IDs for 4 versions of your customer, Maria Gonzalez. Each source has its own source ID (e.g: the SubscriberKey for a marketing subscriber, the ID in Commerce Cloud, etc).
Then, these profiles are unified in Data Cloud, into a single Unified Profile, with a Unified ID that keeps all the source IDs as data lineage.
Finally, if we were to activate Maria Gonzalez as a segment for a marketing campaign, for example, Data Cloud would select one of the source IDs as a Golden Record ID to identify Maria in that target of the Activation.
The Unified ID of a Unified Profile is not meant to be used as a Golden Record ID.
The Golden Record is one of the source IDs, selected when Activation takes place (since the final target of an activation is meant to be static, as a final snapshot of the customer attributes).
Identity Resolution Implementation Steps
These are the usual steps and order followed when implementing Identity Resolution in Data Cloud:
-
- Profile your data sources
- Create Rulesets
- Define Match Rules & Match Methods
- Configure Reconciliation Rules
- Identity Resolution Processing
- Validate Data Results
Profiling Data Sources
This step is about understanding all your source data, field values, etc to see if the source data meets expectations for Identity Resolution.
Create Rulesets
Rulesets are combinations of Match Rules and Reconciliation Rules.
Rulesets allow you to have up to 2 different Profile Unification sets per data space in a Data Cloud Org.
Follow these steps to create a Ruleset:
- Go to Identity Resolution tab > New > Create New Ruleset
- Give the Ruleset a Name and Description
- Entity Objects is the list of the DMOs that Data Cloud will create after running Identity Resolution
You can only have up to 2 different Rulesets for Identity Resolution per data model and data space in a single Data Cloud Org.
If you want to create a new Ruleset while already having 2 sets, you’ll have to remove one of them first, which includes removing its dependencies.
Please check the following link to see the official Salesforce documentation on identity Resolution Rulesets:
https://help.salesforce.com/s/articleView?id=sf.c360_a_identity_resolution_ruleset_create.htm&type=5
Define Match Rules & Match Methods
First, you need to configure Match Rules and their Match Methods in a Ruleset. These are the rules that Data Cloud will use to identify linked customer profiles.
Some considerations:
- Match Rules can leverage any mapped object from the Individual Data Model.
- Match Rules can leverage both Standard and Custom fields from those mapped objects.
- Match Rules are made of rules or criteria.
- Each criterion you create has a Match method.
- As long as 1 Match Rule = TRUE, 2 Individual records will be matched as a linked profile.
- If you want, you may add more rules to make Matching stricter, or remove rules to make matching loose.
- You may modify or extend each rule/criteria.
Here is an example of what 2 Match Rules criteria look like:
| Object | Attribute | Match Method | Match on blank |
|---|---|---|---|
| Individual | First Name | Exact | N |
| Individual | Last Name | Fuzzy | Y |
Each Match Rule criterion has a Match Method. That is, a way of comparing values to see if they match in multiple source profiles, the precision of data matching.
These are the Match Methods available and some considerations:
| Match Method | Fields Supported | Considerations & Example |
|---|---|---|
| Exact | All Fields (Phone, Email, Address, Name, Device, party ID) | Exact value. E.g: Jane Austen = Jane Austen |
| Normalized | Only Name and Contact Point fields (email, phone, address, name) | Very common for email address or phone number. E.g: david@test.com "david@test.com" |
| Fuzzy | Only First Name field | Supports Latin-1 (ISO-8859-1) characters. E.g: Fuzzy First Name David = Dave |
Let’s now look at some examples.
Match Rule: Fuzzy First name + Exact Email Address
As long as multiple customer versions of our example, Anne, have the same email address, all their names would be matched:
#1
Name: Anna
Email: anne@personalemail.com
#2
Name: Anne
Email: anne@personalemail.com
#3
Name: Ann
Email: anne@personalemail.com
Data Cloud has training datasets based on international names, human review, AI training, etc to conclude that these 3 customer profiles are the same person’s names (fuzzy rule), as they share the exact same email address.
Match Rule: Exact Normalized Email
Even if multiple source profiles have different source IDs, as long as they share the exact same email address after normalization, they are linked into the same person in Data Cloud:
#1
ID: id-0001
Email: <luca@personal.com>
#2
ID: id-0002
Email: “luca@personal.com”
#3
ID: id-0003
Email: luca@personal.com
For normalization, Data Cloud works on common spelling mistakes, transpositions, etc. Also, match rules are meant to contain more than 1 criterion, to make them more robust.
For example, for a Normalized Address match rule, a good example would be:
Match Rule: Normalized Address + Exact City + Exact Normalized Country
#1
Address: West 143rd Street
City: New York
Country: U.S.A
#2
Address: west 143 street
City: New York
Country: US
The Consolidation Rate is the % by which profiles were considered a match.
If your Match Rules are very loose, with multiple ORs (#1 rule OR #2 rule OR #3 rule OR #4 rule), you might have a very high Consolidation Rate (all your profiles are matched because it is a broad rule set).
It is considered a best practice to reduce the number of Match Rules (with few ORs and more ANDs conditions) so the rules are stricter and your Consolidation Rate is reduced.
Adding more Match Rules options (#1 OR #2 OR #3 OR #4) increases your Consolidation Rate (not ideal, too many matches, too broad).
Removing Match Rules (few ORs with more ANDs) lowers your Consolidation Rate (more accurate data matching).
Please check the following link to see the official Salesforce documentation on Match Rules and Match Methods:
https://help.salesforce.com/s/articleView?id=sf.c360_a_match_rules.htm&type=5
Configure Reconciliation Rules
The second element of an Identity Resolution ruleset is Reconciliation Rules.
Reconciliation here means: out of all the source profiles of a customer, how should Data Cloud select “the winner” value for the Unified Profile value displayed?
Say you have 4 source profiles for a customer named Peter.
How should Data Cloud decide what value the attribute “First Name” in the Unified Profile will have?
Reconciliation = your company’s preferences for selecting that value.
Here’s a table with all the Reconciliation options that Data Cloud offers:
| Reconciliation Type | Description | Example |
|---|---|---|
| Source Priority | This option sorts all the source values in terms of your company's preferred order, from least to most preferred. You order the source objects and the first one takes precedence. | You have 2 source objects with a value "First Name" for a customer, Sophia. Contact = Sophia eCommerce Customer Profile = Sofia If Contact goes before eCommerce Customer Profile and reconciliation is "Source priority" for First Name, the final selected value will be "Sophia". |
| Last Updated | This option decides that the value which was most recently updated should be the one selected. This option requires the attribute Last Modified Date mapped from the Data Stream. When two values have the same "Last Modified Date", the next order to apply is alphabetical. | In the same example as above, you decide that the field "Last Name" will be selected with "Last Updated" reconciliation rule. If the Last Name in eCommerce Customer Profile was updated more recently than the Last Name in the object Contact, then the first value will be the winner for the Unified Profile. |
| Most Frequent | This rule determines that the value that is found the most in all your sources should be the one selected. If NULL is the most frequently found value, this cannot be selected. If two values have the exact same frequency, then the next rank to apply is by Last Modified Date. | You have a lot of First Name values for a customer called Anna: Anna, Anne, Ann However, "Anne" appears the most in all your source data (7 times as opposed to the others only having one occurrence). The rule will select Anne as the value to select in the Unified Profile. |
Reconciliation Rules do not apply to Contact Points (e.g: email, phone, app, address).
Data Cloud keeps ALL the Contact Points of a customer in their Unified Profile, as they all need to be available later on, when segmenting and activating to different targets.
To configure Reconciliation Rules for an Object in Data Cloud, follow these steps:
- Go to the record page of your Identity Resolution Ruleset.
- Select the object (it expands on clicking).
- Click on the Edit icon beside “Default Reconciliation Rule:”
- Under Default Reconciliation Rule, open the dropdown and select your preference.
- Check or uncheck “Ignore Empty Values”
- Save
This Default Reconciliation Rule will apply to ALL the fields in the selected Object.
If you want to specifically modify Reconciliation Rules for a certain attribute:
- From the Object in the Identity Resolution Ruleset page, click on the specific field.
- Uncheck the toggle “Default Reconciliation Rule”
- Configure the new Reconciliation Rule for this field.
- Save
Please check the following link to see the official Salesforce documentation on Reconciliation Rules:
https://help.salesforce.com/s/articleView?id=sf.c360_a_reconciliation_rules.htm&type=5
Process Identity Resolution
You’ve configured your Identity Resolution Ruleset with its two elements:
- Match Rules
- Reconciliation Rules
Now, it’s time to actually run Identity Resolution and see what results look like.
From the Identity Resolution Ruleset record page, click on the top right button Run Ruleset to start processing records.
After the first run, there will be some available stats for you to check how it went, in the Resolution Summary details section. Here’s all the info available in Data Cloud:
| Name | Description |
|---|---|
| Ruleset Name | The name you gave to the Ruleset. |
| Ruleset Status | Available values: - Error: there is a problem with the ruleset processing. - Delete failed: it could not be deleted. - Deleting: its deletion is in progress. - New: it was created but no Matching or Reconciliation rules have been added yet. It hasn't run for the first time yet either. - Publishing: publishing of the ruleset is in progress. - Published: ruleset is published. |
| Last Job Status | Each run is called a "job" in Ruleset Execution. Available status options: - Scheduled: ruleset job is ready and waiting to run - In Progress: the job is processing - Succeeded: job processing finished correctly - Succeeded with Warnings: job ran correctly but there were errors with some records that need trouleshooting. - Failed: the job run failed. - Error: there was a problem running the ruleset. - Skipped: the job run has been skipped because there were zero changes to records in the source DMO, data streams, ruleset configuration, etc. - Blank: ruleset was created but it doesn't have match or reconciliation rules added yet. |
| Source Profiles | This is the total count of source profiles in the source DMOs. |
| Total Unified Profiles | This figure is the total number of Unified customer profiles that have been created from this ruleset processing. |
| Consolidation Rate | The % of source profiles that were matched into Unified customer profiles. This is a % figure calculated like: 1 - (number of unified individuals / number of source individuals) E.g: if you have 170 Unified Profiles out of 200 source profiles, consolidation rate is = 1 - 0.85 = 15% (15% of your source profiles were merged). |
| Known Unified Profiles | The number of Unified Profiles that were created with at least 1 known source profile (known = non-anonymous data). |
| Anonymous Unified Profiles | The number of Unified Profiles that were created with only anonymous source profiles. |
Finally, in the tab Processing History you can see a list of all the job runs of the Identity Resolution Ruleset with some data such as the Run Date, Total Source Profiles, Processed records, etc.
Known and Anonymous Profiles in Identity Resolution
Unifying known and unknown customer data is important for Identity Resolution and using unified profiles in later Segmentation and Activations.
- A Unified Individual Profile is considered Known when it was created out of at least 1 known source customer profile.
- A Unified Individual Profile is considered Anonymous when it was created out of ONLY anonymous source profiles.
If a Source Individual Profile is identified later on, the anonymous profile –> becomes known.
Important: only Known Unified Profiles count towards your entitlement limit in Data Cloud, so a best practice is to create a “test” ruleset to experiment with Matching and Reconciliation rules and then deleting this ruleset.
Please check the following link to see the official Salesforce documentation on Known and Unknown customer profiles:
Validate Data Results
This step involves checking your results and investigating the Unified Profiles which Data Cloud created.
Salesforce suggests some recommended questions to ask yourself:
- Source Data
Is all the data from Data Streams in Data Cloud?
Were there any errors or unexpected results?
Are all the corresponding Data Mappings correctly configured? - Unified Results
Is the Consolidation Rate an expected figure?
Does the Consolidation Rate make sense?
Do Unified Profiles have the info you expected to see based on mappings, matching rules and reconciliation rules?
In order to get answers to these questions, you can check Data Cloud Profile Explorer.
To inspect Unified Profiles in Profile Explorer:
- Go to Profile Explorer tab
- Select Data Space
- Select Unified Data Model Object
- Select an Attribute and value to search for
Results will display Unified Individual Profiles with their attributes and values for you to check. You can click on VIEW to inspect a specific record.
This is very useful to check if, for instance, the resulting Unified Profiles have the values you expected based on Reconciliation Rules for objects and fields, or if the matching method is giving you the correct result, etc.
Salesforce Data Cloud allows you to configure different Lightning Apps to customise and expand the Profile Explorer experience.
You may add components to the record view page based on your Data Cloud user’s interface preferences and insights needed.
Link to the Lightning Apps documentation:
https://help.salesforce.com/s/articleView?id=sf.c360_a_data_cloud_lightning_apps.htm&type=5
Required Data Model Mappings in Identity Resolution
Data Cloud cannot unfiy profiles through Identity Resolution unless the necessary data model mappings are correctly configured.
The data that requires data model mappings for Identity Resolution is:
-
- Account data
- Individual data
- Party data
- Contact Point data
This makes sense if you think about it:
Individual / Account —> Party + Contact Data (1:N)
Account and Individual are the objects you can create unified profiles on, using 1:N Party for each Individual or Account identifications.
Then, you also need Contact Point data linked to these in order to segment and activate those unified profiles.
Please check the following link to see the official Salesforce documentation on required mappings for Identity Resolution:
Account Object Data Modelling
Required mappings for the Account object are always 1:N in cardinality with Contact Point data and Party identifications because one account can have multiple contact points or party identifications.
Similarly, required mappings for Contact Points or Party to Account are always N:1, as many contact points or party identifications can belong to one single Account.
Here’s a table of all the required mappings:
| Object Name | API Name | Field Labels | Field API Names | Required Mapping |
|---|---|---|---|---|
| Account | ssot__Account__dlm | - Account Id (PK) - Account Name | - ssot__Id__c - ssot__Name__c | 1. Account.ID --> ContactPointApp.Party 2. Account.ID --> PartyIdentificationId.Party 3. Account.ID --> ContactPointPhone.Party 4. Account.ID --> ContactPointEmail.Party 5. Account.ID --> ContactPointAddress.Party |
| Contact Point Address | ssot__ContactPointAddress__dlm | - Contact Point Address Id (PK) - Party - Address Line 1 - City - State Province - Postal Code | - ssot__Id__c - ssot__PartyId__c - ssot__AddressLine1__c - ssot__CityId__c - ssot__StateProvinceId__c - ssot__PostalCodeId__c | 1. ContactPointAddress.Party --> Account.ID |
| Contact Point App | ssot__ContactPointApp__dlm | - Contact Point App Id (PK) | - ssot__Id__c | ContactPointApp.Party --> Account.ID |
| Contact Point Email | ssot__ContactPointEmail__dlm | - Contact Point Email Id (PK) - Party - Email Address | - ssot__Id__c - ssot__PartyId__c - ssot__EmailAddress__c | ContactPointEmail.Party --> Account.ID |
| Contact Point Phone | ssot__ContactPointPhone__dlm | - Contact Point Phone Id (PK) - Party - Formatted E164 Phone Number | - ssot__Id__c - ssot__PartyId__c - ssot__FormattedE164PhoneNumber__c | ContactPointPhone.Party --> Account.ID |
| Party Identification | ssot__PartyIdentification__dlm | - Party Identification Id (PK) - Party - Party Identification Type - Identification Number - Identification Name | - ssot__Id__c - ssot__PartyId__c - ssot__PartyIdentificationTypeId__c - ssot__IdentificationNumber__c - ssot__Name__c | PartyIdentificationId.Party --> Account.ID |
Individual Object Data Modelling
Required mappings for the Individual object will always be 1:N in cardinality with Contact Point data and Party Identification because one Individual can have multiple contact points or party identifications.
Similarly, required mappings for Contact Points and Party Identifications to Individual will always be N:1, as many contact points or party identifications can belong to one single Individual.
| Object Name | API Name | Field Labels | Field API Names | Required Mapping |
|---|---|---|---|---|
| Individual | ssot__Individual__dlm | - Individual Id (PK) - First Name - Last Name | - ssot__Id__c - ssot__FirstName__c - ssot__LastName__c | 1. Individual.ID --> ContactPointApp.Party 2. Individual.ID --> PartyIdentificationId.Party 3. Individual.ID --> ContactPointPhone.Party 4. Individual.ID --> ContactPointEmail.Party 5. Individual.ID --> ContactPointAddress.Party |
| Contact Point Address | ssot__ContactPointAddress__dlm | - Contact Point Address Id (PK) - Party - Address Line 1 - City - State Province - Postal Code | - ssot__Id__c - ssot__PartyId__c - ssot__AddressLine1__c - ssot__CityId__c - ssot__StateProvinceId__c - ssot__PostalCodeId__c | 1. ContactPointAddress.Party --> Individual.ID |
| Contact Point App | ssot__ContactPointApp__dlm | - Contact Point App Id (PK) | - ssot__Id__c | ContactPointApp.Party --> Individual.ID |
| Contact Point Email | ssot__ContactPointEmail__dlm | - Contact Point Email Id (PK) - Party - Email Address | - ssot__Id__c - ssot__PartyId__c - ssot__EmailAddress__c | ContactPointEmail.Party --> Individual.ID |
| Contact Point Phone | ssot__ContactPointPhone__dlm | - Contact Point Phone Id (PK) - Party - Formatted E164 Phone Number | - ssot__Id__c - ssot__PartyId__c - ssot__FormattedE164PhoneNumber__c | ContactPointPhone.Party --> Individual.ID |
| Party Identification | ssot__PartyIdentification__dlm | - Party Identification Id (PK) - Party - Party Identification Type - Identification Number - Identification Name | - ssot__Id__c - ssot__PartyId__c - ssot__PartyIdentificationTypeId__c - ssot__IdentificationNumber__c - ssot__Name__c | PartyIdentificationId.Party --> Individual.ID |
Unified Link Objects
Data Cloud Identity Resolution creates Unified Link objects.
These are “bridge” objects that connect the source data to the unified data with a default 1:1 relationship.
For example, if your company has 4 customer profiles for a customer named Sarah and then Identity Resolution creates 1 Unified Profile Sarah out of those 4 source profiles, that relationship is recorded in the Unified Link Individual object like:
Sarah Source Profile #001 –> Sarah Unified Profile #0123
Sarah Source Profile #002 –> Sarah Unified Profile #0123
Sarah Source Profile #003 –> Sarah Unified Profile #0123
Sarah Source Profile #004 –> Sarah Unified Profile #0123
Each source profile has a 1:1 relationship with the “master” Unified Profile as they are the same Individual.
The same takes place for Contact Point objects, for example. The 4 email addresses that you have for Sarah have a corresponding 1:1 relationship in a Unified Link Contact Point Email object.
These are the Unified Link objects that are created automatically with Identity Resolution:
| Object Name | API Name | Fields | Field API Names |
|---|---|---|---|
| Unified Link Individual | IndividualIdentityLink__dlm | - Individual Id - InternalOrganizationId - Unified Individual Id - Data Source Object - Data Source - CreatedDate | - SourceRecordId__c - ssot__InternalOrganizationId__c - UnifiedRecordId__c - ssot__DataSourceId__c - ssot__DataSourceObjectId__c - CreatedDate__c |
| Unified Link Account | UnifiedLinkssotAccount__dlm | - Account Id - InternalOrganizationId - Unified Account Id - Data Source Object - Data Source - CreatedDate | - SourceRecordId__c - ssot__InternalOrganizationId__c - UnifiedRecordId__c - ssot__DataSourceId__c - ssot__DataSourceObjectId__c - CreatedDate__c |
| Unified Link Contact Point Email | ContactPointEmailIdentityLink__dlm | - Contact Point Email Id - InternalOrganizationId - Unified Contact Point Email Id - Data Source Object - Data Source - CreatedDate | - SourceRecordId__c - ssot__InternalOrganizationId__c - UnifiedRecordId__c - ssot__DataSourceId__c - ssot__DataSourceObjectId__c - CreatedDate__c |
| Unified Link Contact Point Phone | ContactPointPhoneIdentityLink__dlm | - Contact Point Phone Id - InternalOrganizationId - Unified Contact Point Phone Id - Data Source Object - Data Source - CreatedDate | - SourceRecordId__c - ssot__InternalOrganizationId__c - UnifiedRecordId__c - ssot__DataSourceId__c - ssot__DataSourceObjectId__c - CreatedDate__c |
| Unified Link Contact Point Address | ContactPointAddressIdentityLink__dlm | - Contact Point Address Id - InternalOrganizationId - Unified Contact Point Address Id - Data Source Object - Data Source - CreatedDate | - SourceRecordId__c - ssot__InternalOrganizationId__c - UnifiedRecordId__c - ssot__DataSourceId__c - ssot__DataSourceObjectId__c - CreatedDate__c |
| Unified Link Contact Point App | ContactPointAppIdentityLink__dlm | - Contact Point App Id - InternalOrganizationId - Unified Contact Point App Id - Data Source Object - Data Source - CreatedDate | - SourceRecordId__c - ssot__InternalOrganizationId__c - UnifiedRecordId__c - ssot__DataSourceId__c - ssot__DataSourceObjectId__c - CreatedDate__c |
| Unified Link Party Identification | PartyIdentificationIdentityLink__dlm | - Party Identification Id - InternalOrganizationId - Unified Party Identification Id - Data Source Object - Data Source - CreatedDate | - SourceRecordId__c - ssot__InternalOrganizationId__c - UnifiedRecordId__c - ssot__DataSourceId__c - ssot__DataSourceObjectId__c - CreatedDate__c |
When there is more than 1 Identity Resolution Ruleset in Data Cloud, the ruleset ID name is appended to both Link Object Names and Link Object API names to differentiate the different resulting link objects.
For instance, if your ruleset ID is “test”, these 2 object names would be:
Unified Individual Test (API name: UnifiedssotIndividualTest__dlm)
Unified Contact Point Email Test (API name: UnifiedContactPointEmailTest__dlm)
Link to the Unified Link Objects documentation:
https://help.salesforce.com/s/articleView?id=sf.c360_a_identity_resolution_data_modeling_unified_and_link_objects.htm&type=5
Identity Resolution Timings and Limits
A final element to consider is how often Identity Resolution jobs can run.
There are 2 main ways you can run Identity Resolution:
- On Demand
This applies when you make changes to rules within the Ruleset: you create a new rule, update matching rules, configure new reconciliation rules, etc.Latency –> this refreshes instantly and you’re allowed to perform this type of manual update up to 4 times every 24 hours per ruleset per data space.
- Scheduled
By default, automatic runs of Identity Resolution Rulesets are executed every day in batch. You may edit a Ruleset to disable automatic runs if needed. Also, if there are no changes to source data, object mappings or ruleset configurations, a daily run is skipped.Latency –> this batch update takes place every 24 hours unless the job run is skipped due no data changes.
For a detailed breakdown of all the limits and guidelines in Data Cloud Identity Resolution (run limits, timings, max number of profiles, etc) please visit this link to the official documentation:
https://help.salesforce.com/s/articleView?id=sf.c360_a_limits_and_guidelines.htm&type=5
Identity Resolution Recap
In summary, these are the steps and in which order they should be followed to configure and run Data Cloud Identity Resolution:
- Create and Configure Rulesets
- Define Match Rules
- Define Match Method for those rules
- Configure Reconciliation Rules
- Execute or Schedule Identity Resolution
- Validate Results