8.3 Multi-Party Identification, Anonymous-to-Known Transitions & Contact Point Matching
Key Takeaways
- The Party Identification DMO (PartyIdentification__dlm) models authoritative external identifiers (driver's licenses, loyalty numbers, national IDs), requiring both PartyIdentificationNumber and PartyIdentificationType to prevent cross-type key collisions.
- The Anonymous-to-Known transition stitches anonymous web and mobile sessions (DeviceApplication__dlm) to authenticated customer profiles upon login or form submission, preserving complete pre-authentication browsing history.
- Contact Point DMOs (ContactPointEmail__dlm, ContactPointPhone__dlm, ContactPointAddress__dlm) maintain 1:N cardinality with Individual__dlm; match rules evaluate all associated contact points for an individual.
- Data Cloud automatically standardizes contact points into canonical formats (E.164 phone numbers, lowercased emails); mapping contact points to custom text fields on Individual__dlm bypasses normalization and causes matching failures.
- Identity Resolution troubleshooting requires verifying DLO-to-DMO relationship mappings, confirming Data Space scoping, and validating that party identification types are populated.
8.3 Multi-Party Identification, Anonymous-to-Known Transitions & Contact Point Matching
Quick Answer: The Party Identification DMO (
PartyIdentification__dlm) models external identifiers (loyalty numbers, passport numbers, government IDs, and third-party system keys) linked to an individual. Match rules on party identification must always evaluate both Party Identification Number and Party Identification Type to prevent collisions across different numbering domains. In digital channels, Data Cloud executes Anonymous-to-Known Transitions by linking anonymous web/mobile device browsing history (DeviceApplication__dlm) to known profiles when a visitor authenticates or completes a form. Contact points (ContactPointEmail__dlm,ContactPointPhone__dlm,ContactPointAddress__dlm) follow a 1:N relationship withIndividual__dlmand undergo automated platform normalization (such as E.164 formatting) essential for deterministic matching.
Party Identification DMO (PartyIdentification__dlm) Architecture
In complex enterprise ecosystems, customer identity is frequently governed by external, system-specific keys rather than personal contact information. A healthcare network identifies patients via a National Provider/Patient Identifier; an airline identifies flyers via a Frequent Flyer Number; a retail bank identifies clients via a Tax Identification Number (SSN/EIN); and a global enterprise links accounts via an ERP Master Data Management (MDM) ID.
In Salesforce Data Cloud, these external keys are modeled using the Party Identification DMO (PartyIdentification__dlm).
+---------------------------------------------------------------------------------------------------+
| PARTY IDENTIFICATION DMO DATA ARCHITECTURE |
+---------------------------------------------------------------------------------------------------+
| Individual__dlm (1) |
| ┌─────────────────────────────────────────────────────────────────────────────────────────────┐ |
| │ Id: IND-7701 | FirstName: Maria | LastName: Rodriguez │ |
| └──────────────────────────────────────────────┬──────────────────────────────────────────────┘ |
| │ 1:N Relationship (PartyId__c) |
| ▼ |
| PartyIdentification__dlm (N) |
| ┌─────────────────────────────────────────────────────────────────────────────────────────────┐ |
| │ Record 1: │ |
| │ PartyIdentificationId__c: PID-101 │ |
| │ PartyId__c: IND-7701 │ |
| │ PartyIdentificationNumber__c: DL-8890214 │ |
| │ PartyIdentificationType__c: DriversLicense │ |
| │ IdentificationName__c: California DMV │ |
| ├─────────────────────────────────────────────────────────────────────────────────────────────┤ |
| │ Record 2: │ |
| │ PartyIdentificationId__c: PID-102 │ |
| │ PartyId__c: IND-7701 │ |
| │ PartyIdentificationNumber__c: FLYER-993021 │ |
| │ PartyIdentificationType__c: FrequentFlyerNumber │ |
| │ IdentificationName__c: Premier Rewards Loyalty │ |
| └─────────────────────────────────────────────────────────────────────────────────────────────┘ |
+---------------------------------------------------------------------------------------------------+
Core Schema Fields of PartyIdentification__dlm
PartyIdentificationId__c(Text, Primary Key): The unique surrogate identifier for the party identification record within Data Cloud.PartyId__c(Text, Foreign Key): The foreign key linking this identification record directly to theIndividualId__cof anIndividual__dlmrecord.PartyIdentificationNumber__c(Text): The raw alphanumeric identifier value (e.g.,"984-12-8819","LOYALTY-5541","PASSPORT-X19022").PartyIdentificationType__c(Text, Disambiguation Key): The semantic category or namespace of the identifier (e.g.,"DriversLicense","Passport","SocialSecurityNumber","LoyaltyProgram","CoreCRMContactId").IdentificationName__c(Text, Optional): A descriptive label for the issuing authority or system (e.g.,"State of New York","Delta SkyMiles","SAP ERP").
The Critical Role of PartyIdentificationType__c
A frequent exam topic centers on the necessity of including PartyIdentificationType__c in match criteria. Different issuing authorities and software systems frequently assign overlapping numeric sequences:
- Person A has a State Driver's License number:
"1009842" - Person B has a Retail Store Loyalty Number:
"1009842"
If an architect configures a match rule that compares PartyIdentificationNumber__c (Exact) without including PartyIdentificationType__c (Exact), Data Cloud will observe identical string values ("1009842") and erroneously merge Person A and Person B into the same Unified Individual!
[!IMPORTANT] Consultant Mandate: Whenever matching on Party Identification, you must always include both
PartyIdentificationNumber__cANDPartyIdentificationType__cas mandatory criteria within the match rule.
The Anonymous-to-Known Transition Lifecycle
One of the most transformative capabilities of Salesforce Data Cloud is stitching anonymous digital engagement history to authenticated CRM customer profiles. This process is known as the Anonymous-to-Known Transition.
+---------------------------------------------------------------------------------------------------+
| ANONYMOUS-TO-KNOWN PROFILE STITCHING LIFECYCLE |
+---------------------------------------------------------------------------------------------------+
STAGE 1: ANONYMOUS BROWSING
Visitor lands on brand website.
Data Cloud Web SDK drops first-party cookie: UUID-88124.
┌────────────────────────────────────────────────────────────────────────┐
│ Individual__dlm: IND-ANON-991 (Anonymous = True) │
│ DeviceApplication__dlm: UUID-88124 │
│ Engagement: Viewed 'Mountain Bike Pro', Added to Cart ($850) │
└────────────────────────────────────────────────────────────────────────┘
│
▼
STAGE 2: THE IDENTIFICATION EVENT
Visitor completes checkout or submits web lead form.
Enters email: 'clara.oswald@tardis.org' and First Name: 'Clara'.
┌────────────────────────────────────────────────────────────────────────┐
│ Form Submission Event creates ContactPointEmail__dlm: │
│ Email: 'clara.oswald@tardis.org' linked to IND-ANON-991 │
└────────────────────────────────────────────────────────────────────────┘
│
▼
STAGE 3: IDENTITY RESOLUTION EXECUTION
Scheduled or streaming Identity Resolution ruleset evaluates incoming data.
Rule 2 matches: Exact Email ('clara.oswald@tardis.org') + Fuzzy First Name.
┌────────────────────────────────────────────────────────────────────────┐
│ Existing CRM Profile: IND-CRM-4401 (Clara Oswald, Sales Cloud Contact) │
│ Anonymous Web Profile: IND-ANON-991 (Clara, Web Visitor) │
│ Match Rule creates graph edge between IND-CRM-4401 and IND-ANON-991. │
└────────────────────────────────────────────────────────────────────────┘
│
▼
STAGE 4: UNIFIED PROFILE CONVERGENCE & ENRICHMENT
Data Cloud creates Identity Link rows bridging both source IDs.
┌────────────────────────────────────────────────────────────────────────┐
│ UnifiedIndividual__dlm: UNIF-77201 │
│ IndividualIdentityLink__dlm: │
│ - SourceRecordId: IND-CRM-4401 ──▶ UnifiedRecordId: UNIF-77201 │
│ - SourceRecordId: IND-ANON-991 ──▶ UnifiedRecordId: UNIF-77201 │
│ │
│ ALL PRE-LOGIN BROWSING (Mountain Bike Pro view & cart) IS NOW LINKED │
│ TO CLARA'S SERVICE CLOUD CONSOLE & SEGMENTATION AUDIENCES! │
└────────────────────────────────────────────────────────────────────────┘
+---------------------------------------------------------------------------------------------------+
Step-by-Step Architectural Mechanics
- Stage 1 (Anonymous Device Tracking): When an unauthenticated visitor navigates a website or mobile app instrumented with the Salesforce Data Cloud Web/Mobile SDK, the SDK generates a persistent client-side identifier (e.g., first-party cookie or device advertising ID). The ingestion pipeline maps this session to
DeviceApplication__dlmand creates an unauthenticatedIndividual__dlmrecord withIsAnonymous__c = True. - Stage 2 (Behavioral Ingestion): As the visitor clicks products, navigates categories, and abandons shopping carts, these streaming events ingest into Engagement DMOs (
DeviceApplicationEngagement__dlm,SalesOrder__dlm) tagged with the anonymousIndividualId. - Stage 3 (The Identification Trigger): At a critical conversion point—such as registering for an account, logging in, requesting a quote, or completing an e-commerce purchase—the visitor provides an authoritative contact point (Email Address, Mobile Phone, or Account ID).
- Stage 4 (Identity Graph Edge Creation): During the next Identity Resolution execution, Data Cloud evaluates the new contact point. The match rule identifies that the newly provided email on the anonymous web profile matches the email of an existing known Sales Cloud
Contactor Service CloudPerson Account. - Stage 5 (Unified Lineage Binding): The engine writes entries to
IndividualIdentityLink__dlm, pointing both the anonymousIndividualIdand the CRMIndividualIdto the sameUnifiedIndividualId. Crucially, all historical engagement events remain intact and attached to the unified profile. Service agents viewing the Service Cloud console can now see what the customer browsed 20 minutes before logging in, and marketing journeys can trigger personalized abandoned-cart recoveries.
Contact Point DMOs in Matching: 1:N Cardinality & Platform Normalization
A cornerstone of the Customer 360 canonical data model is the separation of individuals from their contact points. In traditional relational databases, a Contact table often includes rigid columns: Email, Secondary_Email, MobilePhone, HomePhone, MailingStreet.
In Data Cloud, this design is replaced with normalized 1:N child Contact Point DMOs linked to Individual__dlm via PartyId__c:
+---------------------------------------------------------------------------------------------------+
| CONTACT POINT 1:N DATA MODEL TOPOLOGY |
+---------------------------------------------------------------------------------------------------+
| |
| ┌──────────────────────┐ |
| │ Individual__dlm │ |
| │ (Party / Person) │ |
| └──────────┬───────────┘ |
| │ 1:N |
| ┌─────────────────────────────────────┼─────────────────────────────────────┐ |
| │ │ │ |
| ▼ ▼ ▼ |
| ┌───────────────────────────┐ ┌───────────────────────────┐ ┌───────────────────────────┐ |
| │ ContactPointEmail__dlm │ │ ContactPointPhone__dlm │ │ ContactPointAddress__dlm │ |
| │ - EmailAddress__c │ │ - TelephoneNumber__c │ │ - AddressLine1__c │ |
| │ - EmailType__c (Work/Home)│ │ - FormattedE164Phone... │ │ - PostalCodeText__c │ |
| │ - PartyId__c │ │ - PhoneType__c (Mobile) │ │ - City__c / CountryName__c│ |
| └───────────────────────────┘ └───────────────────────────┘ └───────────────────────────┘ |
+---------------------------------------------------------------------------------------------------+
Graph Traversal Across 1:N Contact Points
Because an individual can have multiple active emails, phones, and addresses, Data Cloud's match engine traverses the entire collection of child contact points during match evaluation:
- If Candidate Individual 1 has 3 email records (
work@corp.com,personal@gmail.com,old@alumni.edu) - If Candidate Individual 2 has 2 email records (
personal@gmail.com,consultant@biz.org) - The match engine evaluates all combinatorial pairs. Because
personal@gmail.commatches between Candidate 1 and Candidate 2, a graph edge is successfully formed!
Platform-Managed Automated Normalization
Deterministic matching on text strings is notoriously fragile if data is unstandardized. To ensure high-precision matching without requiring complex custom ETL pipelines, Data Cloud executes automated platform normalization when data is mapped to standard Contact Point DMOs:
| Contact Point DMO | Standard Canonical Field | Automated Platform Normalization Applied | Match Rule Optimization |
|---|---|---|---|
ContactPointEmail__dlm | EmailAddress__c | 1. Strips leading and trailing whitespace.<br/>2. Converts all alphabetic characters to lowercase.<br/>3. Validates against RFC 5322 syntax. | Evaluated with Exact Match. Guarantees that John.Doe@ACME.com matches johndoe@acme.com. |
ContactPointPhone__dlm | FormattedE164PhoneNumber__c | 1. Strips punctuation, dashes, spaces, and parentheses.<br/>2. Resolves country code based on source or default tenant country.<br/>3. Formats to international standard: +[CountryCode][AreaCode][Number] (e.g., +14155550199). | Evaluated with Exact Match. Guarantees that (415) 555-0199 and 415.555.0199 match perfectly. |
ContactPointAddress__dlm | AddressLine1__c, PostalCodeText__c | 1. Standardizes street suffixes ("Street" → "St", "Avenue" → "Ave").<br/>2. Trims whitespace and normalizes postal code casing. | Evaluated with Fuzzy Street Address and Exact Postal Code. Handles minor typos and unit abbreviations. |
[!CAUTION] The Custom Field Trap: If an implementation maps raw phone numbers or email addresses to custom text fields on
Individual__dlm(e.g.,Individual__dlm.RawPhone__c) instead of the canonicalContactPointPhone__dlmobject, automated platform normalization will NOT run. Match rules comparing custom text fields will treat(415) 555-0199and415-555-0199as different strings and fail to match!
Troubleshooting Identity Resolution: The Consultant's Diagnostic Guide
When Identity Resolution rulesets fail to produce expected matches or encounter processing errors, consultants must systematically isolate the breakdown across the data pipeline.
IDENTITY RESOLUTION DIAGNOSTIC WORKFLOW
│
▼
Are expected source records consolidating
into Unified Profiles?
│ │
YES NO
│ │
│ ▼
│ Check Data Space Assignment:
│ Are both source records mapped
│ within the SAME Data Space?
│ │
│ YES ────┴──── NO ──▶ Reassign records to
│ │ same Data Space
│ ▼
│ Verify DLO-to-DMO Mapping:
│ Is PartyId__c correctly mapped
│ between Contact Point & Individual?
│ │
│ YES ────┴──── NO ──▶ Correct foreign key
│ │ mapping in Data Streams
│ ▼
│ Check Normalization Fields:
│ Is match rule evaluating
│ FormattedE164PhoneNumber__c?
│ │
│ YES ────┴──── NO ──▶ Update match rule to
│ │ canonical normalized field
│ ▼
│ Check PartyIdentificationType:
│ Are PartyIdentification records
│ populated with identical types?
│
▼
Are records over-grouping into Mega-Clusters?
│
YES ────┴──── NO ──▶ Ruleset Healthy
│
▼
Audit Profile Explorer for:
1. Unfiltered placeholder values (e.g., 'test@test.com')
2. Low-entropy rules (LastName alone, EmailDomain)
3. Unanchored fuzzy matching rules
Comprehensive Consultant Troubleshooting Matrix
| Symptom / Failure Mode | Probable Architectural Root Cause | Diagnostic Verification Technique | Remediation Steps |
|---|---|---|---|
| Records with identical phone numbers fail to merge. | 1. Phone number is mapped to a custom field instead of canonical ContactPointPhone__dlm.<br/>2. Match rule evaluates raw TelephoneNumber__c instead of FormattedE164PhoneNumber__c.<br/>3. Missing country code prevented E.164 standardization. | Inspect ContactPointPhone__dlm in Data Explorer. Check whether FormattedE164PhoneNumber__c is null or improperly formatted. | Update data stream formula to supply default country code (+1); update match rule to reference FormattedE164PhoneNumber__c. |
| Records fail to merge across different systems despite matching emails. | 1. Records belong to different Data Spaces.<br/>2. ContactPointEmail__dlm.PartyId__c was mapped to a source system ID rather than the source IndividualId__c. | Query ContactPointEmail__dlm and verify that PartyId__c matches Individual__dlm.IndividualId__c. Verify Data Space assignment in Setup. | Re-map the foreign key PartyId__c in Data Stream mapping. Ensure all participating data streams are assigned to the correct Data Space. |
| Unrelated customers merge after loyalty card scan. | Match rule evaluates PartyIdentificationNumber__c (Exact) without filtering on PartyIdentificationType__c (Exact). Different systems used identical numeric sequences. | Inspect the merged Unified Individual in Profile Explorer. View linked PartyIdentification__dlm records to identify conflicting ID types. | Modify the match rule immediately to enforce composite matching: PartyIdentificationNumber__c (Exact) AND PartyIdentificationType__c (Exact). |
| Anonymous web visitors fail to stitch upon form submission. | 1. The form submission event created a new Individual record without associating the SDK cookie or session ID.<br/>2. Web SDK ingestion latency or missing identity resolution run. | Check DeviceApplication__dlm and IndividualIdentityLink__dlm in Data Explorer to see if web session ID was captured. | Ensure the Web SDK identify API event is called upon form submission to pass the authenticated email alongside the anonymous cookie ID. |
| Identity Resolution ruleset job times out or fails. | Graph density explosion: An anti-pattern match rule (e.g., matching on shared generic email or last name) created a mega-cluster with millions of edges, exceeding graph engine memory limits. | Review Identity Resolution job status and error logs. Look for 'Graph cluster size exceeded threshold' warnings. | Identify and remove the unanchored match rule. Add ingestion filters in Data Prep/Streams to exclude placeholder values (noemail@domain.com, 999-999-9999). |
A hospital network ingests patient records from three regional clinics and a national health registry. The data team maps patient identifiers into the Party Identification DMO (PartyIdentification__dlm). Clinic A uses internal patient charts (e.g., 'ID-99412'), while the national registry uses state-issued driver's license numbers. Which match rule configuration must the consultant implement to prevent unrelated patients from merging if an internal chart number matches a driver's license number?
An online luxury retailer deploys the Salesforce Data Cloud Web SDK on their e-commerce storefront. An unauthenticated visitor browses several high-end watches, adds a $5,000 chronograph to their shopping cart, but navigates away before purchasing. Two days later, the visitor clicks an email newsletter, arrives on the site, and logs in with their registered account. What happens to the visitor's prior cart activity during the subsequent Identity Resolution run?
An enterprise consultant is troubleshooting an Identity Resolution ruleset. Candidate records representing the same individual in Sales Cloud (phone entered as '(555) 019-2831') and Service Cloud (phone entered as '555.019.2831') are failing to merge under a match rule configured with 'Exact Phone Number'. What is the most likely architectural root cause?