The Party Identification objects in Data Cloud are used for the Identity Resolution function. When I first encountered the concept, I didn’t immediately understand what was happening under the hood. However, after sitting with it and performing three implementations, it clicked.
I will explain how the Party Identification Data Model Objects (DMOs) work architecturally and how to set them up to enable matching based on a contact or account’s external ID.
Definition and Concept
The Party Identification data model object (not to be confused with Party DMO) is a junction object that allows external identifiers in Identity Resolution for accounts and contacts. A person or account can have several types of party identifiers, and the object creates distinct rows for them with their names and types.
When mapping an account or contact to Party Identification, you populate the object for ID resolution for unified accounts or individuals along with Contact Point Objects. Contact Points and Party Identification are the only objects available to use as unification criteria other than the object you’re unifying. Therefore, any custom objects used for profile unification must be mapped to at least Party Identification.
Using Multiple Identification Numbers
Values for name and type in the Party Identification DMOs differentiate IDs from multiple external systems. If you unify accounts and contacts for B2B use cases, you will have different party identification names for each. Formula fields on the source DLO enable the differentiation of multiple external IDs likely found in your profile DLOs.
Party Identification Definitions
For any data stream used in Identity Resolution with a DLO profile, mapping and relationships with Party Identification should be created.
Data Model
| DMO Name | Field Name | Cardinality | DMO Name | Field Name |
|---|---|---|---|---|
| Party Identification | Party Identification ID | 1:1 | Unified Link Party Identification | Party Identification ID |
| Unified Link Party Identification | Unified Party Identification ID | N:1 | Unified Party Identification | Unified Party Identification ID |
The relationships are automatically created when rulesets are run for account and individual unification, but different objects are made for each. Account unification will create DMOs Unified Link Party Identification Acct and Unified Acct Party Identification Acct. The data model applies to both cases, but the names will differ depending on what you’re unifying.
FK = Foreign Key
Field Definitions
| Field Label | Field Name | Use | Source |
|---|---|---|---|
| Party Identification ID | ssot__Id__c | Primary key for Party Identification DMO | Formula field with UUID |
| Party Identification Type | ssot__PartyIdentificationTypeId__c | String denoting the type of identification | Formula field on DLO |
| Party Identification Name | ssot__Name__c | A string describing the party | Formula field on DLO |
| Identification Number | ssot__Identificationnumber__c | Matching Party Identification records from your profile DLOs | The external ID or other foreign key used for matching |
| Party | ssot__PartyId__c | Individual ID | The source DLO’s primary key is mapped to Individual ID (e.g. contact ID) |
How to Set the Foundation for Identity Resolution
Formula Fields to Create on Profile Data Lake Objects
The DLOs mapped to Party Identification require at least three formula fields to differentiate multiple Party Identification Numbers.
- Party Identification ID: The primary key of the record you create when mapping a DLO to the Party Identification DMO. It’s inadvisable to map the primary key of the DLO to this field because that key will be mapped to the Party field to identify the source record ID for the many unified source profiles. A formula field is recommended using a value without spaces.
- Party Identification Name: A required field to differentiate party identification numbers if you use more than one in your rules, such as unifying accounts and contacts. This should be unique (e.g. you can concatenate the name of your identification and the ID to be used).
- Party Identification Type: An optional field to categorize party identification names. This should be the same value for all rows.
Example Mappings With Contact
| Field Label | Sample Value | Target Field | Field Name |
|---|---|---|---|
| Contact Party ID | 001f2000023VI7kAAY | Party Identification ID | ssot__Id__c |
| Contact Identification Type | DescriptiveTypeIndicator | Party Identification Type | ssot__PartyIdentificationTypeId__c |
| Contact Party Identification Name | DescriptiveIdentifierName | Party Identification Name | ssot__Name__c |
| External System ID | 37482012 | Identification Number | ssot__Identificationnumber__c |
| Contact ID | 001f2000023VI7kAAY | Party | ssot__PartyId__c |
Relationships of Party Identification with Profile Objects
Party Identification must be related to the individual for contact and/or lead unification. For account unification, Party Identification and Account must be related.
| DMO Name | Field Name | Cardinality | DMO Name | Field Name | Use |
|---|---|---|---|---|---|
| Party Identification | Party | N:1 | Individual | Individual ID | Individual unification using Account Contact DMO |
| Party Identification | Party | N:1 | Account | Account ID | Account unification using Account DMO |
Considerations
The Identification Name and Identification Type are static values not tied to a specific record but that link a party identification number across several sources for ID resolution. For example, ID resolution rules can use multiple party identifications defined by their names and types. But, if you want to use various party IDs from the DLO, transform the data to an interim DLO and map it to the Party Identification DMO.
However, because only one Identification Number can be mapped from a source DLO to a Party Identification DMO, the chosen ID should be carefully considered as part of the overall design before construction.
Up to two Identity Resolution rulesets can be created for an individual or account – consider which Party Identification you will use for each and whether you will have customers without another ID to match.
For example, customers with transactions usually have an ID from another system, while prospects would not because they have no transactions. It is inadvisable to resolve IDs solely using email or other contact information – Party Identification should be included. The reliability and consistency of external IDs should be clearly understood before deciding which to use.
Set Up Party Identification as a Match Rule in Identity Resolution
Create a new match rule using Party Identification and configure it to specify the Identification Name upon which to match individuals or accounts.
- Create a new custom rule in your ruleset.
- Create a rule using the Party Identification Number as shown below.
- Specify the Party Identification Name and Party Identification Type. The values below are samples that would be the output of your formula fields.
The above can be paired with other criteria if you suspect you may have duplicates from different systems. But if this is the primary key of your external system, you may use this criterion alone despite the warning symbol. In the case of only unifying accounts from CRM, you can use Party Identification for accounts with this field as an external ID. However, when accounts don’t have an external ID, other looser contact point-based match rules require several criteria.
Summary
The Party Identification setup helps determine the accuracy of Identity Resolution, so it should be designed with an understanding of the concept and data model. The consolidation rate itself does not indicate success or failure. If the identification numbers chosen to create profiles don’t apply to a large population or are inconsistent, your other rules must accommodate these gaps. Therefore, Party Identification design and configuration are crucial to the success of your Data Cloud implementation.
Any thoughts? Don’t forget to leave them in the comments below.
