Data 360 Identity Resolution: Style Guide | Cleon

This is the page where Cleon stops describing what identity resolution is and starts saying how we tune it. Salesforce defines the surfaces. The reference pages in this subcategory document each one — the unified individual it produces, the match rules that decide who is the same person, the reconciliation rules that pick which value wins, the keys you resolve on, and how resolved identity feeds everything downstream — and the gotchas document where resolution quietly fails. This Style Guide is the discipline that keeps a ruleset trustworthy the day it runs across a whole org and decides which humans are the same human.

Use it as a checklist before any ruleset is created or changed. The rules are short on purpose — when a rule needs an explanation, the explanation is in the page it links to. One decision sits above all the others, so it goes first.

The central decision: how strict should the match be?

Almost every identity resolution choice in Data 360 (formerly Data Cloud) reduces to one fork: do you tune the rules toward consolidation — loose, so more source records collapse into one unified individual — or toward precision — strict, so a record only merges on strong evidence? Loosen too far and two different people fuse into one profile and can see each other's data; tighten too far and one person fragments across several profiles and nothing reconciles. Get this right and the rest of the subcategory is detail. Get it wrong and both failures are silent — no error fires either way — and the fix is a ruleset change that reprocesses the org, not a setting you flip.

Three questions decide it. Answer them in order.

1. What's the cost of a false merge here versus a false split?

The two failure modes are not equally bad, and you must name which one this org or use-case can least afford out loud, first — before you touch a single criterion. A false merge (over-merge, rules too loose) leaks one customer's data into another's profile: they see each other's orders, suppression leaks across them, and in a consent-bearing channel it is a privacy incident, not a metrics nuisance — the worse failure in most B2C and consent-bearing contexts. A false split (over-split, rules too strict) fragments one person into several profiles: metrics double-count, a suppression set misses some of their records, and the single view quietly isn't one. Both are silent. Decide which risk the rules lean against deliberately, and let that asymmetry set the default strictness — most consent-bearing work leans toward precision and treats a false merge as the unacceptable one.

2. Do you have a strong deterministic key, or only probabilistic signals?

The strictness you can afford is capped by the keys you resolve on. A clean, verified deterministic key — a party identification value such as a loyalty or CRM ID, a confirmed personal email, a personal mobile — lets you lean stricter and match on equality with confidence; exact match on a strong key is the most defensible thing a rule can do. Only fuzzy signals — a free-text name plus geography — force you looser, and a fuzzy criterion must stay anchored to an exact key in the same rule (recall a match rule is an AND of its criteria), never standing alone, and never the sole basis for a consent-bearing channel. If the only key you have is a name, the honest answer is that you cannot resolve safely yet — fix the key, do not loosen the rule.

3. Has the business signed off on the rules against real data — and is reprocessing budgeted?

Identity resolution is a business decision, not a checkbox — principle 4. Which source is authoritative for email, whether a name-only match is ever acceptable, what counts as a strong key here: these are answerable only with someone who owns the data, validated against real records, not best-practice slides. And the cost has a second half. Changing match or reconciliation rules triggers reprocessing across the org: the engine re-evaluates source records, recomputes the IndividualIdentityLink__dlm mappings, rebuilds the unified profiles — it costs (Data 360 bills on work processed, principle 11), it takes time, and the unified counts shift the moment it runs. Budget the reprocessing and warn whoever reads the counts before you change a live rule, not after the numbers move.

This is the exact parallel to the segmentation layer's batch publish versus real-time data action call, one layer over — a deliberate fork with two failure modes and a reprocess, not a rebuild, behind the wrong pick — and to the same business-sign-off discipline: tune identity to the failure the business can least afford, never to whatever the defaults happened to produce.

Patterns to prefer

The unacceptable failure named first — false merge or false split — and the strictness set to lean against it on purpose.
An exact criterion on a strong deterministic key (party ID, verified email, personal mobile) as the backbone of every ruleset.
Fuzzy name anchored to an exact key in the same rule — fuzzy-name AND phone-exact, never name alone — and reserved for contexts where a false merge is genuinely cheap.
Normalization confirmed on every match key before the ruleset runs, so an over-split doesn't come from casing or phone formatting.
Reconciliation chosen per attribute, with Source Priority where a system of record exists and recency only where the timestamp means a real human edit.
The ruleset tested against real data with the business signed off — principle 4 — before it runs on the whole org.
Reprocessing budgeted and the shifting unified counts announced before a live rule changes, not explained after.

Patterns to refuse

A fuzzy name-only rule on a consent-bearing audience — the classic over-merge, two people fused and then seeing each other's data.
A "loosen it until the counts look right" tuning pass — chasing a target unified count with no view on whether the right people merged.
Source-to-unified joined directly to check what a rule did — the path doesn't exist in the model; always traverse IndividualIdentityLink__dlm.
A strong-looking key trusted without an actual-uniqueness audit — a re-used loyalty ID or an info@ address mapped as personal merges people who aren't the same.
The ruleset default accepted on every attribute because configuring each is tedious — that's how a verified birthdate flips every time a low-quality feed re-imports.
A rule changed on a live org with no reprocessing budget and nobody warned that the counts are about to move.
"It resolved" treated as "it resolved correctly." No error fires for either failure — verify against real records (debugging identity resolution).

The agent-readiness check

A coherent unified individual is the prerequisite for an agent to answer about a customer — agent-ready is a property of the model, not a feature you bolt on (principle 10). The check is one line: if a human analyst can't get a single correct picture of this customer from the unified profile, neither can an agent — Agentforce or an external LLM. Identity resolves before a profile is agent-ready: a person fragmented across three unified rows, or two people merged into one, breaks the analyst and the agent equally, and no amount of prompt engineering fixes a profile that resolved wrong underneath. The strictness call in this guide is, in the end, the call that decides whether the model can be grounded on at all.

The pre-ship checklist before any ruleset change ships

[ ] The unacceptable failure is named — false merge or false split — and the strictness is set to lean against it on purpose, not left at the default.
[ ] Every match rule has an exact criterion on a strong deterministic key; no fuzzy criterion stands alone, and none drives a consent-bearing channel on its own.
[ ] Match keys are confirmed populated, actually unique, and normalized before the ruleset runs.
[ ] Reconciliation is set per attribute — Source Priority where a system of record exists, recency only where the timestamp reflects a real human edit — not the ruleset default everywhere.
[ ] The ruleset was tested against real data and the business owner signed off (principle 4), before it runs on the whole org.
[ ] Reprocessing is budgeted — cost and time — and whoever reads the unified counts has been told they will shift.
[ ] What the change did was verified by inspecting IndividualIdentityLink__dlm, never a direct source-to-unified join.
[ ] The unified profile is coherent enough that an analyst — and therefore an agent — can get one correct answer about a customer (principle 10).

When all of them fire, the ruleset is ready to ship.

The unified individual — what resolution produces, and the IndividualIdentityLink__dlm bridge the strictness call ultimately shapes
Match rules — the OR-of-AND-groups the false-merge-vs-false-split decision tunes
Reconciliation rules — once matched, which attribute value wins in the unified profile
Match keys and normalization — the deterministic-vs-probabilistic distinction question 2 turns on
Unified identity downstream — why every count, segment, and agent inherits this decision
Identity resolution gotchas — the silent failures, the production version
Debugging identity resolution — diagnosing over-merge and over-split after the fact
Data 360 principles from production — the meta-rules above these specifics (4, 10, 11)

If you spot a rule missing — or one of these rules being violated in our public work — write to hello@wearecleon.com. We add it, or we fix it and we say so.