Identity resolution in Data 360

There are two ways identity resolution fails, and they are not equally bad. Under-merge leaves the same customer sitting in three unified profiles: annoying, visible, fixable. Over-merge fuses two different customers into one profile — and then every system downstream acts on the hybrid. Marketing emails greet Maria by James’s name. A service agent, human or AI, reads out someone else’s order history. A segment activates one person’s loyalty balance to another person’s inbox. That last scenario isn’t a data-quality bug; it’s a privacy incident.

The frustrating part is that both failures come from the same screen in Salesforce Data 360 (the platform formerly known as Data Cloud): the identity resolution ruleset, a short list of match rules and reconciliation rules that most teams configure in an afternoon and then regret for a quarter. The rules themselves are simple. The behavior they produce at millions of records — transitive chains, placeholder-value pileups, consolidation rates that look impressive right up until you inspect a profile — is not.

This post walks through how identity resolution actually works in Data 360, why careless fuzzy matching over-merges, and a conservative-first implementation sequence with the monitoring and credit math to iterate safely.

How identity resolution works in Data 360: ruleset, match rules, unified profiles

Identity resolution runs after ingestion and mapping. Your source systems land data in data lake objects, you map them to data model objects (DMOs) like Individual, Contact Point Email, and Party Identification, and only then does unification have anything to unify. A ruleset sits on top of those DMOs and contains two kinds of logic: match rules and reconciliation rules. Each data space supports up to two rulesets, which matters for testing later.

Match rules decide which source records represent the same person. Each rule holds one or more criteria — a field plus a match method — and the logic is strict in one direction, loose in the other: all criteria within a rule must pass (AND), but a match on any single rule is enough to unify (OR). Add a second match rule and you haven’t refined your matching; you’ve widened it. This asymmetry is the single most important fact about the feature, and it’s the mechanical reason “just add another rule” is usually the wrong instinct.

When the ruleset runs — within 24 hours of first publishing, then in daily batches, with a limited number of manual re-runs per day per ruleset — it produces unified individual profiles along with unified link objects that map every source record to its unified parent. Nothing is destroyed. Source records stay intact in their DMOs, which is why identity resolution is reversible in principle: fix the rules, re-run, and the profiles regroup. In practice, as we’ll get to, re-running has a price tag.

Scale is worth a sentence here, because it explains some platform behavior. Salesforce engineering has described scaling the matching pipeline from 50 million to 2 billion source records, with individual unified clusters reaching up to 50,000 matched records. Fifty thousand. No real human generates fifty thousand source records; a cluster that size is almost always a placeholder value doing exactly what you told it to do.

Exact, normalized, and fuzzy match methods — and when each earns its place

Every criterion in a match rule uses one of three match methods, and choosing between them is where precision is won or lost:

Match method	What it tolerates	Best for	Over-merge risk
Exact	Nothing — same value or no match	Stable system identifiers: loyalty ID, customer number, party identifiers	Low — unless the identifier is reused or defaulted
Exact normalized	Formatting only: casing, punctuation, phone formats	Email, phone, address — anything machines format differently	Low-moderate — shared emails and household phones
Fuzzy	Typos, nicknames, variants, at a precision you choose	Human-entered names; certain address fields like city	Moderate to high, rising as precision drops

Exact matching is what it sounds like: no typos or alternative formats accepted. Normalized matching treats [email protected] and [email protected] as the same value, and (02) 9555-0100 as +61295550100 — same information, different formatting. Fuzzy matching accepts genuinely different values that probably refer to the same person, and it’s the interesting one.

Fuzzy matching in Data 360 is model-driven, not a wildcard. Salesforce trained language models that score name pairs by confidence, and you pick one of three precision levels. The naming trips people up, so read this twice: high precision is the strictest setting, not the smartest one. High precision still matches well-established nicknames — William and Bill, Catherine and Katherine, José Andrés and Pepe. Medium adds initials and shuffled names: S. matches Sharon, Joey James matches James Joseph. Low precision accepts loose similarity like Lisa and Liza, which also means it accepts a lot of coincidence.

Two implications follow. First, fuzzy name matching is safe only as a secondary signal — fuzzy first name AND normalized email is a reasonable rule; fuzzy name AND fuzzy city is a merge generator. Second, precision level is a business decision, not a technical one. A healthcare or financial-services org confusing Johnathan Smith with John Smith has a compliance problem; a retailer missing the match has a slightly less complete segment. Decide which failure you can live with before you touch the dropdown.

The over-merge disaster: how two real customers become one unified profile

Over-merges rarely come from one obviously bad rule. They come from reasonable-looking rules interacting with real data in three specific ways.

Placeholder and default values. Source systems love defaults: John Smith, [email protected], 0000000000, the store’s own address on every point-of-sale record. Match on any of these and thousands of strangers unify. This is the usual origin of those monster clusters — the engine will happily build a profile toward its 50,000-record cluster ceiling out of everyone who shares a call-center default. The fix is upstream: exclude or null out junk values in a transform before unification ever sees them.
Shared contact points. Families share landlines and home addresses. Colleagues share office phones and info@ mailboxes. A rule matching phone and address alone will fuse a married couple into one person — technically a match, commercially a mess. Contact-point criteria need a person-level criterion (name, at sensible precision) alongside them.
Transitive chaining. Matching is transitive: if record A matches B on email, and B matches C on phone, then A, B, and C unify — even though A and C share nothing. Every extra OR’d rule adds new edges to this graph, and fuzzy rules add weak edges cheaply. Stack three loose rules and you’ve built a daisy chain where one shared household phone bridges two otherwise distinct identity clusters.

Here’s the disaster in miniature. Maria Alvarez and her adult son Mario live at the same address and share a home phone. Rule 1: fuzzy name (low precision) plus normalized address — Maria/Mario passes. Rule 2: normalized phone plus fuzzy first name — passes again. One unified profile now holds two people. Reconciliation picks one birthdate, one email as the “best” value, and your birthday campaign, your consent flags, and your Agentforce service agent all inherit a person who does not exist. Neither customer complained about duplicates before. Both will complain now.

The reverse failure — under-merge — is real but self-announcing: customers get asked to repeat themselves, segments undercount, and the missed matches show up as visibly duplicate profiles you can inspect. Over-merge hides. Wrong data looks like data. That asymmetry is the entire argument for starting conservative.

Reconciliation rules: deciding which attribute wins in the unified profile

Match rules decide who merges; reconciliation rules decide what the merged profile says. When five source records disagree about first name or birthdate, the reconciliation rule for that attribute picks the winner from three options:

Last updated — the most recently modified source value wins. Sensible default behavior, but it quietly trusts your worst-governed system if that system happens to write most often.
Most frequent — the value appearing in the most source records wins. Democratic, and exactly wrong when three stale records outvote the one current one.
Source priority — you rank sources by trust, and the highest-ranked source with a value wins. This is the one we end up recommending in most orgs, because teams usually do know that the loyalty platform’s email beats the e-commerce guest checkout’s.

You can set a default at the object level and override it per field — source priority for identity attributes, last updated for a mobile number, and so on. One structural detail saves a lot of confusion: reconciliation governs single-value attributes, not contact points. All unique emails are still stored on the unified profile; reconciliation isn’t throwing the losers away, just choosing what displays and activates as the value.

Note what reconciliation cannot do: it cannot rescue an over-merged profile. It only chooses among values that matching already grouped. If Maria and Mario are fused, source priority just decides whose birthdate the ghost customer gets. Get matching right first; reconciliation is a second-order optimization.

A conservative-first implementation sequence in five steps

Every tuning conversation runs the same direction: it’s cheap to loosen rules and painful to tighten them, because tightening means profiles split and downstream references shift. So start deterministic and earn each loosening step with evidence.

Fix the data before it reaches the ruleset. Trailhead’s own guidance is blunt: it’s easier to fix a data stream before ingestion than after. Profile each source for placeholder names, dummy emails, and shared-identifier patterns, and null them out in batch transforms. Ten minutes of blocklisting [email protected] prevents the ugliest cluster you’d otherwise build.
Start with deterministic identifiers only. First ruleset: exact match on party identifiers — loyalty number, customer ID, any identifier a system assigned rather than a human typed — plus exact normalized email. Nothing fuzzy. Run it, and treat the resulting consolidation rate as your baseline of near-certain matches.
Seed known test identities before you trust anything. Plant a handful of synthetic customers whose fate you know in advance: the same person with a typo’d name across two sources (should merge), a parent and child sharing address and surname (should not), two colleagues sharing an office phone (should not). After each run, look these profiles up in Profile Explorer. Aggregate stats can’t tell you which records merged; your test identities can, and they turn every future rule change into a pass/fail check instead of a vibe.
Loosen one criterion at a time, and A/B it. Now add the human-entered signals: fuzzy first name at high precision plus normalized phone, then exact last name plus normalized address if the evidence supports it. Use the second ruleset slot to A/B test a candidate against your incumbent on the same data, and compare consolidation rates and your test identities before promoting. One change per iteration — two simultaneous rule edits make results unattributable.
Stop when new matches stop being right. Each loosening step should produce a modest consolidation bump and zero broken test identities. The step that produces a big bump is not a win; it’s the step that started matching strangers. In our experience most orgs land on two or three match rules with two or three criteria each — anything longer is usually compensating for data quality problems that belong upstream.

Sequencing this well is less about Data 360 expertise and more about knowing your sources’ trust levels and failure patterns — which is exactly the groundwork a data and AI strategy engagement is supposed to surface before anyone publishes a ruleset.

Monitoring consolidation rates and the credit cost of re-running unification

The number you’ll watch is the consolidation rate — the share of source profiles that merged away into unified ones, which Salesforce surfaces per run and even offers as a calculated insight for tracking over time. Roughly: 1 − (unified profiles ÷ source profiles). Ten million source profiles consolidating into six million unified ones is a 40% rate.

Here’s the trap: the metric reads like a score, and it isn’t. Adding match rules raises the rate; removing them lowers it — so anyone can hit any number they like. A consolidation rate that jumps after a rule change, or that lands far above what your known duplication levels predict, is evidence of over-merging, not effectiveness. If your sources are mostly distinct customer bases and the ruleset still reports 70% consolidation, something is fusing strangers. Judge the rate against expectation per source — a re-ingested CRM with heavy duplication should consolidate hard; a clean loyalty file shouldn’t.

Three checks catch most problems early:

Largest-cluster review. Query the unified link objects for the profiles with the most source records and read the top twenty. Placeholder pileups announce themselves immediately.
Test-identity assertions after every run, as above.
Run-over-run deltas in the ruleset’s processing history — a stable pipeline that suddenly consolidates 5% more without a rule change means a source started shipping junk values.

Iteration also has a bill attached, and it’s worth knowing before you plan weekly rule tweaks. On Salesforce’s published rate card, batch profile unification consumes 100,000 credits per million source profiles processed as of early 2026 — orders of magnitude above nearly every other meter on the card. Mercifully, after a ruleset’s first run only new and modified source profiles count toward usage, so steady-state daily runs bill the delta. But change the rules and, in practice, you should plan for the full source volume to reprocess. On 20 million source profiles, that’s roughly two million credits per iteration — real money at list price, and the reason the discipline above (transform upstream, one change at a time, validate on test identities before publishing) is a cost-control measure as much as a quality one. It’s also a reason to keep anonymous profiles out of your unification scope unless a use case genuinely needs them.

Unified profiles are a trust exercise

Strip away the terminology and identity resolution is your org making a public claim: these records are the same human being. Every activation, every segment, every Agentforce answer repeats that claim to an actual customer, which is why the tolerable error rate is so much lower than for most analytics work. A dashboard that’s 95% right is useful. A unified profile that’s 95% right sends 5% of your customers someone else’s data.

The good news is that nothing in this discipline is exotic. Match rules are OR’d, criteria are AND’d, so fewer rules with more criteria is the conservative shape. Fuzzy matching is a scored model with a precision dial, so treat the dial as a business decision and keep fuzzy criteria chaperoned by deterministic ones. Consolidation rate is a diagnostic, not a KPI. Test identities convert rule changes from hope into assertion. And the credit meter prices in exactly the behavior you should avoid anyway — thrashing rules on full production volume instead of changing one thing, measuring, and moving deliberately.

Teams that internalize this end up somewhere valuable: a unified profile they’ll let an AI agent read aloud to a customer without flinching. That’s the actual bar now. Under-merge costs you completeness, and completeness can be earned back one careful rule at a time. Over-merge costs you trust, and trust doesn’t re-run overnight.

Understanding the basics

What is identity resolution in Salesforce Data 360?

Identity resolution is the Data 360 process that links records about the same person or account across data sources into one unified profile. A ruleset defines match rules (which records belong together, using exact, normalized, or fuzzy comparison) and reconciliation rules (which value wins when sources disagree). It’s non-destructive: source records remain intact, and unified link objects preserve the trail from every source record to its unified profile.

What is a good consolidation rate in Data 360?

There’s no universal target. The consolidation rate — roughly 1 minus unified profiles divided by source profiles — reflects how much duplication your sources actually contain, so a heavily duplicated CRM should consolidate far more than a clean loyalty file. Judge the rate against expectation per source and watch for sudden jumps after rule changes. A rate far above predicted duplication usually signals over-merging, not better matching.

What is the difference between match rules and reconciliation rules?

Match rules decide which source records unify into one profile: all criteria within a rule must match, and satisfying any one rule is enough to merge. Reconciliation rules act afterward, choosing which value populates each single-value attribute on the unified profile — by last updated, most frequent, or source priority. Reconciliation can’t fix a bad merge; it only picks among values that matching already grouped together.

Tuning match rules in your own Data 360 org — or cleaning up after a merge that went too far? Talk to us — it’s what we do.

Identity resolution in Data 360: a practical guide to match rules that don't over-merge