Identity Resolution
Identity Resolution is the Salesforce Data Cloud process that merges multiple source records representing the same real-world person into one canonical Individual profile.
Definition
Identity Resolution is the Salesforce Data Cloud process that merges multiple source records representing the same real-world person into one canonical Individual profile. The same human might appear as a Salesforce Contact, a Marketing Cloud Subscriber, an external loyalty member, and a Service Cloud Case Contact across four different systems. Identity Resolution applies match rules (exact email, normalized phone, fuzzy name plus date of birth) to identify which source records belong to the same person and assigns them a shared Unified Individual ID.
The output is one Unified Individual record per real person, with links back to every source record that contributed to the match. Downstream Customer 360 features (segmentation, calculated insights, activations, prompt grounding) operate on the unified Individual rather than on the fragmented source records. Identity Resolution is what makes Customer 360 actually a 360-degree view; without it, the platform has the same person three times and counts them as three customers.
How Identity Resolution dedupes cross-source records into one canonical Individual
Match rules and the rule engine
Identity Resolution is configured through Match Rules. Each rule describes a way to identify the same person across sources: Exact Match on email, Exact Match on normalized phone, Fuzzy Match on FirstName plus LastName plus DateOfBirth, hashed identifiers from a customer login system. Multiple rules can fire; if any rule matches between two source records, they merge. The rule order matters; high-confidence rules (exact email) run first, fuzzier rules later. Rule design is the highest-leverage Identity Resolution decision.
Match keys and normalization
Match rules operate on Match Keys, which are normalized versions of source attributes. Email match keys lowercase and trim whitespace. Phone match keys strip formatting and country codes. Name match keys handle case and common abbreviations (Robert / Bob, William / Will). Normalization is what makes fuzzy-feeling matches deterministic and reproducible. Custom normalizations can be defined for industry-specific identifiers (vehicle VIN, insurance policy number, healthcare member ID).
Reconciliation rules: which source wins on each field
Once two source records merge into one Unified Individual, conflicting field values must reconcile. A Sales Cloud Contact might have FirstName Robert; a Marketing Cloud Subscriber might have FirstName Bob. Reconciliation Rules decide which source wins per field: Most Recent (latest update), Source Priority (Sales Cloud always wins over Marketing Cloud), or Custom Logic. The reconciliation choice affects the unified profile attribute values; downstream segmentation reads the reconciled value.
Unified Individual ID and the link back to sources
Each unified Individual gets a stable Unified Individual ID. The original source records keep their source IDs; Data Cloud stores the link between source ID and unified ID in a junction table. Customer 360 features can query either layer: "give me every email engagement for this unified Individual" or "give me the raw source records that map to this unified Individual." The dual-layer model is what lets ops teams audit how the platform decided two records were the same.
Materialization cadence and reprocessing
Identity Resolution runs on schedule: hourly, every 6 hours, daily. Each run incrementally adds new source records to the existing unified profile, applies rules, and updates the unified Individual list. Full reprocessing reruns every source record through every rule from scratch; expensive but necessary after major rule changes. Most production deployments run incremental hourly or daily with occasional full reprocesses planned during maintenance windows.
Match quality and the false-merge risk
Identity Resolution is probabilistic on fuzzy rules. Two people with the same FirstName, LastName, and DateOfBirth could falsely merge if no stronger identifier disambiguates them. Tight match rules (insist on email or phone) trade fewer matches for higher confidence. Loose rules (allow fuzzy name plus zip code) trade more matches for occasional false merges. Production deployments typically start tight and loosen carefully, monitoring merge-quality metrics.
Survivorship across source updates
When a source record updates (Sales Cloud Contact gets a new email), Identity Resolution reprocesses on the next run. The new email might newly match a different unified Individual, splitting the merge. Or it might keep the same merge unchanged. Salesforce ships Survivorship Rules that govern how mid-flight changes affect existing unified profiles. Unified Individual IDs are stable when possible but not guaranteed across reprocessing.
Setting up Identity Resolution match and reconciliation rules
Setup runs in three phases: design match rules, configure reconciliation, and run the first materialization. Plan iteration; the first rule set rarely matches business reality on day one.
- Inventory source-system identifiers
Before writing rules, list every identifier each source system has: email, phone, member ID, login ID, hashed identifiers. Coordinate with each source-system owner to confirm what identifiers are reliable enough to match on.
- Build the match rule set
Data Cloud, Identity Resolution, New. For each source-pair, add a match rule. Start with high-confidence exact-match rules (email, phone) and add fuzzy rules (name plus DOB) as needed. Order rules by confidence; high-confidence rules run first.
- Configure reconciliation rules
For each Unified Individual attribute (FirstName, EmailAddress, City), pick how conflicts resolve. Most Recent is the common default; Source Priority works when one source is canonically trusted (CRM beats marketing platform).
- Run the initial materialization
Trigger the Identity Resolution job. Wait for completion (can take hours on large source data). Review the unified Individual count versus expected count; large gaps indicate match rules need adjustment.
- Audit and iterate
Sample unified Individual records. Verify the right source records merged. Look for false merges (different people merged together) and missed merges (same person not merged). Tune rules and reprocess.
Exact match, normalized match, fuzzy match. Each has different precision and recall trade-offs.
Most Recent (latest update wins), Source Priority (configured source order), Custom (per-field logic). Pick per attribute.
Hourly, every 6 hours, daily, on-demand. Match to data freshness need and credit budget.
Standard normalizations for email, phone, name. Custom normalizations for industry-specific identifiers.
- Fuzzy match rules risk false merges. Two people with the same name and birth date merge incorrectly without a stronger disambiguator.
- Reconciliation choice affects every unified Individual attribute value. Wrong reconciliation produces a unified profile that contradicts both source records.
- Full reprocessing is expensive but sometimes necessary after major rule changes. Plan during maintenance windows.
- Unified Individual IDs are not guaranteed stable across reprocessing. Downstream systems that bookmark IDs need a reconciliation strategy.
- Match quality is measurable but easy to ignore. Sample audits catch false and missed merges before they cascade.
Trust & references
Cross-checked against the following references.
- Identity Resolution OverviewSalesforce Help
- Match RulesSalesforce Help
Straight from the source - Salesforce's reference material on Identity Resolution.
- Reconciliation RulesSalesforce Help
- Unified Profiles in Data CloudSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Identity Resolution in Data Cloud?
Q2. Why is identity resolution foundational to CDPs?
Q3. What needs ongoing tuning in identity resolution?
Discussion
Loading discussion…