Data 360: Party Identifier Match Rule is not Unifying all Matching Profiles in Identity Resolution

Confirm that the Party field on Party Identification DMO matches the Individual ID or Account ID

Party Identifier in Identity Resolution Match Rules details that the Party (ssot__PartyId__c) field on Party Identification is used as a foreign key to link Party Identification to the DMO that is being unified (e.g. Individual or Account). 

"Party: This ID field is a foreign key to an account or individual. A relationship must exist between account ID or individual ID and this field."

If you go to the Party Identification DMO in the Data Model tab and check the Relationships for this data model object you should see that the Party field is referenced in the relationship between Party Identification and the Individual DMO. In order for Individuals to match based on a Party Identifier match rule the value in the Party field must be the same as the Individual ID on the Individual DMO. This usually means that mapping the Party field to the same field on the Data Lake Object that is mapped to the Individual ID on Individual.

Confirm the same value exists in Party Identification Type, Identification Name and Identification Number

In the examples provided in Party Identifier in Identity Resolution Match Rules, we see that when you configure a Party Identifier match rule you enter a Party Identification Type (ssot__PartyIdentificationTypeId__c) and Identification Name (ssot__Name__c) value in the Match Rule Criteria popup. These are static values that describe the party identifier. Often these fields are mapped to formula fields on the data stream that ensure the same value is present in these fields for all records ingested by a data stream. 

In the Match Rule Criteria, you also select the Identification Number (ssot__IdentificationNumber__c) field with the Match Method as Exact. The Identification Number field contains the unique identifier that is used to match the profiles. For profiles to match based on the Party Identifier match rule they need to share the same values in all 3 of these fields. 

Example Scenario

Given the following records in the Party Identification DMO and assuming that all IDs in the Party column exist as Individual IDs in the Individual DMO, we can expect the following outcomes if our Identity Resolution has a Party Identifier match rule with 'PersonIdentifier' as the Party Identification Type and 'PassportNumber' as the Party Identification Name:

• Party 123 and 345 will be unified and will share a Unified Individual ID as they have the same value in Party Identification Type, Identification Name and Identification Number.
• Party 234 will have its own Unified Individual ID as it will not be matched with any other profiles as no other profile has the Identification Number P4444. 
• Party 456 will have its own Unified Individual ID as it does not have 'PersonIdentifier' in Party Identification Type or 'PassportNumber' in Identification Name and therefore cannot meet the match rule criteria despite having the same value as Party 123 and 345 in Identification Number. If the requirement is for Party 456 to be unified with Party 123 and 345 then we would need to review the data stream that ingested this record and the mapping between the DLO and the Party Identification Type and Identification Name fields on Party Identification.

Ensure Party Identification Id is Unique

The field Party Identification Id (ssot__Id__c) is the primary key for Party Identification DMO. During Identity Resolution processing, records with the same Data Source (ssot__DataSourceId__c), Data Source Object (ssot__DataSourceObjectId__c) and Party Identification Id are deduplicated as these fields combine are expected to be unique. This can lead to some unexpected outcomes if a Party Identification Id is shared by multiple records - particularly records with different Party IDs.

Example Scenario

Assuming all records listed below have a matching Party Identification Type and Identification Name, we can see that the combination of Data Source, Data Source Object and Party Identification Id cannot be used to uniquely identify records as Party IDs 123 and 345 have the same values in those fields and Party IDs 234 and 456 also have matching values in those fields.

As Party Identification DMO records are automatically deduplicated during Identity Resolution processing so that there is only one record with the same values in Data Source, Data Source Object and Party Identification Id, this will in effect mean that only one Party ID from each of these pairs will be unified and will share a Unified Individual ID. The Party ID whose corresponding record on Party Identification DMO is ignored as a result of deduplication during processing cannot be matched based on the Party Identifier match rule and will instead get its own Unified Individual. So for example:

• Party ID 123 and 456 are matched based on the Party Identifier match rule and will share a Unified Individual ID.
• The records on Party Identification DMO with Party ID 234 and 345 are deduplicated during Identity Resolution due to these records sharing the same values in Data Source, Data Source Object and Party Identification Id as Party ID 456 and 123 respectively. As a result, neither of these Party IDs can be matched with other profiles based on the Party Identifier match rule and will instead each get their own Unified Individual.
• As a result, we will see 3 Unified Individual generated for these records instead of 1 Unified Individual.

To avoid this issue, we need to ensure that the Party Identification Id is unique when combined with the Data Source and Data Source Object column. This would be achieved in the above scenario, if the Party Identification Id included a reference to the ID in Party and not just the Identification Number. So for example, Party Identification Id should be PassportNumber-P5555-123 for Party ID 123.