Study guide
8.3 Multi-Party Identification, Anonymous-to-Known Transitions & Contact Point Matching
Salesforce Certified Data 360 Consultant formerly Data Cloud Consultant
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Solution Overview & Enterprise Value
1.1 Enterprise Customer 360 & Data Cloud Business Value 1.2 Architectural Foundation: Zero-Copy, Hyperforce, Lakehouse & Data Pipeline 1.3 Platform Terminology, Core Entities & Data Lifecycle Stages 1.4 Data 360's Foundational Role in Predictive & Generative AI
2 Chapter 2: Ethics, Privacy & Governance Fundamentals
2.1 Regulatory Compliance, Data Privacy & Ethics in Customer Data 2.2 Consent Management & Preference Enforcement in Data Cloud 2.3 Data Retention, Deletion, and Privacy Right-to-be-Forgotten (RTBF)
3 Chapter 3: Security, Permissions & Tenant Architecture
3.1 Standard Permission Sets, User Roles & Functional Access 3.2 Data Spaces Architecture, Resource Allocation & Tenant Isolation
4 Chapter 4: Administration, Monitoring & Lifecycle Management
4.1 Data Kits & Package Automation for Cross-Org Deployment 4.2 Auditing, Status Monitoring, Error Logs & Data Explorer 4.3 Sandboxes, Change Management & Metadata Deployment
5 Chapter 5: Ingestion Connectors & Source Integration
5.1 Standard Bundles & Salesforce CRM Connectors (Sales/Service/Marketing) 5.2 Cloud Storage (S3, GCS, Azure Blob) & Streaming Ingestion (Web/Mobile SDK, Ingestion API) 5.3 Zero-Copy Data Federation & Snowflake/BigQuery/Databricks Sharing
6 Chapter 6: Data Lake Objects (DLO) & Data Transformations
6.1 DLO Configuration, Primary Keys, Event Time & Data Stream Categories (Profile, Engagement, Other) 6.2 Streaming & Batch Data Transforms: Formula Fields, SQL Transforms & Data Prep Recipes
7 Chapter 7: Data Model Objects (DMO) & Canonical Harmonization
7.1 Customer 360 Canonical Data Model & Subject Areas 7.2 DLO-to-DMO Mapping Patterns, Cardinality & Custom DMO Design 7.3 Data Validation, Schema Maintenance & Field Mapping Best Practices
8 Chapter 8: Identity Resolution Architecture & Match Rules
8.1 Identity Resolution Concepts, Consolidation Rate & Graph Modeling 8.2 Match Rules & Match Criteria: Exact Match vs. Fuzzy Matching (Deterministic & Probabilistic) 8.3 Multi-Party Identification, Anonymous-to-Known Transitions & Contact Point Matching
9 Chapter 9: Reconciliation Rules & Unified Profile Governance
9.1 Reconciliation Rules: Most Frequent, Source Priority & Last Updated 9.2 Unified Profile Schema (Individual & Contact Points) & Resolution Troubleshooting
10 Chapter 10: Segment Architecture & Audience Design
10.1 Segmentation Canvas, Segment Types (Standard UI & Flow) & Query Processing 10.2 Direct vs. Related Attributes, Cardinality & 1:N Filtering Traps 10.3 Segment Schedule, Refresh Frequencies & Exclusion Logic 10.4 Segment Membership Analysis, Population Drift & Sizing Validation
11 Chapter 11: Calculated & Streaming Insights
11.1 Calculated Insights (CI) Architecture, SQL/Builder Syntax & Dimensions vs. Metrics 11.2 Streaming Insights (SI) Architecture, Windowing (Tumbling/Sliding) & Real-Time Signals 11.3 CI vs. SI Architectural Decision Matrix & Performance Optimization
12 Chapter 12: Data Enhancements, Sharing & Analysis
12.1 Referencing Data 360 Data from Other Systems: Enrichments, Related Lists, Data Graphs & APIs 12.2 Reports, Dashboards & Tableau Analysis on Data 360 Data 12.3 Applying Predictive & Generative AI Tooling to Customer Scenarios
13 Chapter 13: Activation Targets & Outbound Activation
13.1 Activation Targets: Marketing Cloud, External Platforms, Cloud Storage & Data Spaces 13.2 Activation Configuration: Audience Mapping, Related Attributes & Payload Optimization 13.3 Activation Schedules, Publishing Cadence & Incremental vs. Full Refresh 13.4 Activation Troubleshooting: Error Logs, Rejection Reasons & Delivery Failures
14 Chapter 14: Real-Time Data Actions & Flow Automation
14.1 Data Action Targets & Webhook/Platform Event Architecture 14.2 Data Cloud-Triggered Flows & Real-Time Business Orchestration 14.3 End-to-End Enterprise Scenario Walkthrough: Ingestion to Closed-Loop Action
8.3 Multi-Party Identification, Anonymous-to-Known Transitions & Contact Point Matching
Key Takeaways Explain This Topic AI
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.
Last updated: September 2026
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 with Individual__dlm and 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 the IndividualId__c of an Individual__dlm record.
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__c AND PartyIdentificationType__c as 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__dlm and creates an unauthenticated Individual__dlm record with IsAnonymous__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 anonymous IndividualId .
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 Contact or Service Cloud Person Account .
Stage 5 (Unified Lineage Binding): The engine writes entries to IndividualIdentityLink__dlm , pointing both the anonymous IndividualId and the CRM IndividualId to the same UnifiedIndividualId . 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.com matches 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.; 2. Converts all alphabetic characters to lowercase.; 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.; 2. Resolves country code based on source or default tenant country.; 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").; 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 canonical ContactPointPhone__dlm object, automated platform normalization will NOT run . Match rules comparing custom text fields will treat (415) 555-0199 and 415-555-0199 as 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 .; 2. Match rule evaluates raw TelephoneNumber__c instead of FormattedE164PhoneNumber__c .; 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.; 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.; 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 ).