Salesforce Data Cloud Identity Resolution Guide: Profiles, Matching, Rules
The short answer
Identity resolution in Salesforce Data Cloud (Data 360) is the process that links data about the same person (or account) across sources into a unified profile using an identity resolution ruleset (match rules + reconciliation rules).
Who this cloud is for
If identity resolution is under-built, you get duplicates (same person split across multiple profiles). If it’s over-built, you get over-merges (different people combined into one profile). Either one breaks segmentation, personalization, analytics, and ROI reporting.
If your goal is “one customer view” → you need identity resolution, not just ingestion and mapping.
If you have high-confidence identifiers (loyalty ID, customer ID, party identifier) → lean on those first, then expand with contact points (email/phone/address) as needed.
If your use case requires immediate matching (for personalization) → consider real-time matching constraints and choose match methods accordingly.
What is a unified profile?
A unified profile is created when Data Cloud runs your identity resolution ruleset to link related records from multiple sources and represent them as a single consolidated view.
How to think about it (simple model):
Source records (CRM records, web/app data, commerce, etc.) stay in their source-shaped structures.
Identity resolution creates a unified identity by matching records that belong together.
Reconciliation rules determine what gets written onto the unified profile when multiple sources disagree.
Identity resolution rulesets: the two parts that matter
Salesforce describes identity resolution as being configured through rulesets that include match rules and reconciliation rules.
1) Match rules = “Which records belong together?”
Match rules tell Data Cloud which profiles to unify during identity resolution. They’re built from one or more criteria.
Practical examples of match criteria
Same email address (normalized)
Same phone (normalized)
Same party identifier / customer ID
Name + address combinations (typically more cautious)
2) Reconciliation rules = “Which value wins?”
When multiple source records have different values for the same attribute, reconciliation rules determine what value is stored in the unified profile.
Common reconciliation approaches Salesforce references include things like source priority and other rule-driven selection methods (the exact set depends on your setup and requirements).
Match methods: exact, normalized, and fuzzy (and when to use each)
Salesforce provides multiple match methods, including exact, exact normalized, and fuzzy/normalized options (depending on the field/object and your configuration).
A practical way to choose
Exact: Use when the identifier is truly stable (loyalty ID, customer ID, some emails).
Exact normalized: Use when formatting varies (phone punctuation, email casing, spacing). Salesforce documents normalization behaviors for match keys.
Fuzzy: Use cautiously—best for “human-entered” fields where typos and variations are common, and only when you can tolerate some uncertainty. Salesforce documents fuzzy matching concepts and algorithms across matching features.
Important caution: Salesforce notes that mixing fuzzy and exact matching types in the same rule can prevent duplicates from being detected in some matching contexts—treat match design as something you test, not assume.
Scheduled vs real-time matching: what changes (and why it matters)
Salesforce supports scheduled and real-time ruleset runs, and they differ in when and how matching is performed.
Implementation reality (what to plan for):
Scheduled matching is typically used for ongoing batch-style unification.
Real-time matching is used for use cases where a system needs to match immediately (for example, certain personalization flows).
Salesforce documents important constraints: for example, in some real-time contexts, match rules are evaluated using Exact or Exact Normalized methods.
The foundation everyone skips: data modeling requirements
Salesforce is explicit that data must be mapped correctly for identity resolution to process it into unified profiles, and it provides data modeling requirements for identity resolution.
Practical takeaway: Identity resolution quality is heavily driven by mapping, keys, and contact point completeness. If those are weak, no amount of “better match rules” will save the outcome.
A simple “profiles & matching” strategy you can copy
Start conservative, then expand coverage
Begin with high-confidence identifiers (party/customer IDs, stable contact points).
Validate unified profiles in Profile Explorer and verify you aren’t over-merging. (Salesforce training highlights Profile Explorer as a core tool for viewing unified profiles.)
Add additional match rules only after you’ve measured match outcomes and confirmed you’re improving consolidation without harming accuracy.
Decide “what wins” before you scale
Define reconciliation with business intent:
Customer support use case might prefer “most recent” values
Compliance use case might prefer “source priority”
Marketing use case might prefer “most complete” values
(Your exact implementation should follow the reconciliation rule options and behaviors Salesforce documents for your environment.)
Troubleshooting: the 3 most common failure modes
1) Under-matching (duplicates everywhere)
When it happens: match rules are too strict, keys aren’t normalized, or key fields aren’t mapped/available.
2) Over-matching (different people merged)
When it happens: fuzzy rules are too permissive or you match on weak identifiers.
3) “Unified profile looks wrong” (bad field values)
When it happens: reconciliation rules aren’t aligned with “source of truth” expectations.
Want a second set of eyes on your identity resolution rules?
If you’re implementing Data Cloud and want to avoid duplicates, over-merges, or “mystery profile” outcomes, book time with our team. We’ll help you:
Choose match keys and methods that fit your data reality
Design reconciliation rules that match your business logic
Set up a testing loop so changes don’t break segmentation later