There is a conversation that happens on almost every Salesforce marketing project, usually around week six. Someone opens a unified profile, finds three email addresses, two first names and a phone number that belongs to a colleague, and asks the question that should have been asked in week one: which one of these is the customer?
That question is identity resolution. It is the least glamorous part of Salesforce Data 360 (the platform formerly branded Data Cloud) and it sets a hard ceiling on everything you can do downstream. No amount of clever content design rescues a segment built on a broken identity graph.
Key takeaways
- Identity resolution is two separate decisions: matching (which records are the same person) and reconciliation (which value wins when they disagree).
- Match rules that are too loose merge different humans. Rules that are too tight leave your best customers fragmented across three profiles.
- Reconciliation rules are where most personalisation bugs actually live — the salutation problem is a reconciliation problem.
- Test the graph with named, known individuals before you test it with counts. Counts hide errors; people reveal them.
- Rebuilding a ruleset is cheap early and expensive after segments, activations and reports are built on top of it.
What "unification" actually means
Data 360 ingests source data as data streams, maps it onto the Customer 360 Data Model, and then runs an identity resolution ruleset to produce unified individual profiles. That last step is the one marketers care about, because the unified individual is what your segments query and what your journeys personalise from.
The important mental shift: unification does not delete or overwrite your source records. Every source contribution survives. What the ruleset produces is a view — a link between source records and a unified profile, plus a decision about which attribute value to expose on that profile. If the view is wrong, the underlying data is still intact and you can rebuild. That is genuinely reassuring, and it is the reason to iterate on rules rather than to clean data upstream forever before you start.
Decision one: match rules
A match rule is a statement of the form “if these attributes agree, treat these records as the same person.” You can run several rules in one ruleset, and they are evaluated together — a record joins a profile if any rule matches.
The three families you will actually use:
| Rule family | Typical definition | Fails when |
|---|---|---|
| Exact identifier | Same normalised email, or same CRM Contact ID | Shared household or role inboxes (info@, family@) merge distinct people |
| Fuzzy name plus identifier | Fuzzy first name, exact last name, exact normalised email | Nicknames handled well; married-name changes still fragment |
| Party identification | Loyalty number, customer number, hashed identifier from a third system | Only as good as the system that issues the number |
Two practical rules of thumb. First, normalise before you match: lowercase emails, decide your policy on plus-addressing, standardise phone numbers to E.164. Data 360 gives you normalisation options on match criteria; use them rather than assuming your sources are consistent, because they are not.
Second, be suspicious of matching on email alone in B2C. Shared inboxes are common enough that a single loose rule can quietly merge a couple into one profile, at which point your personalised email addresses the wrong person by name. In B2B the equivalent trap is matching on company domain.
The over-merge you will not notice
Under-matching is visible: your segment counts look low, and someone complains that a known customer appears twice. Over-matching is invisible in aggregate — the counts look better. You only find it by opening individual profiles and asking whether the linked records really belong to one human.
Decision two: reconciliation rules
Once records are linked, the platform still has to answer: this profile has three first names, which one goes in the email? That is reconciliation, and it is configured separately from matching.
The two strategies that matter:
- Source priority — “trust the CRM value over the web form value over the event import.” Deterministic, explainable to stakeholders, and the right default for anything that appears in a message.
- Most recent — “trust whichever value was written last.” Correct for things that genuinely change, like a delivery address or a marketing consent state.
The mistake is applying one strategy uniformly. Recency is right for consent and wrong for names; source priority is right for names and wrong for the address someone just corrected at checkout. Go attribute by attribute for the handful of fields that actually surface in messages and segments. For everything else, pick a sane default and move on.
Almost every “why did the email say Dear Bob when his name is Robert” ticket is a reconciliation rule that nobody wrote down.
The sequence that keeps you out of trouble
- Inventory the sources first, on one page. For each source: what it is authoritative for, how often it lands, and which identifier it carries. If a source cannot contribute an identifier, it cannot contribute to matching — that is a scoping fact, not a data problem to solve later.
- Pick ten named test people. A clean single-source customer, a customer who exists in three systems, a known duplicate, someone on a shared inbox, someone who changed their surname, an unsubscribed contact, an employee, a test record, a customer with an open service case, and a churned customer. Write their expected unified state down before you build.
- Start narrow. One or two tight match rules. Run the ruleset, then inspect your ten people. Only widen after you know which ones failed to unify and why.
- Reconcile the message-facing attributes deliberately. Salutation, email, mobile, consent, language, country. Those six decide whether your first campaign embarrasses anyone.
- Only then build segments. Segments built on an unstable graph will need rebuilding, and so will everything attached to them.
Where marketers get surprised
Rebuilds take time, and the clock is not on your side
Changing a ruleset triggers re-resolution across your data volume. On a large org this is not instant, and your segment counts will move while it runs. Plan ruleset changes like a deployment, not like a checkbox — including telling the campaign team not to trust counts that day.
Consent is a modelling problem, not a field
Consent lives in its own part of the data model, and it has to survive unification correctly. If two source records disagree — one opted in, one opted out — your reconciliation must resolve to the restrictive value. This is one of the few places where “most recent wins” is not automatically safe: a stale re-import can resurrect an opt-in that someone deliberately withdrew. Decide the rule, document it, and test it with a real withdrawn consent.
Your personalisation ceiling is the graph, not the channel
Teams often arrive with a personalisation wish list — next-best-product, lifecycle stage, replenishment timing — and assume the work sits in the campaign tool. It does not. Every one of those needs an attribute computed on a profile that is reliably one person. Fix the graph and the wish list becomes ordinary work. Skip it and the wish list becomes a series of near-misses that quietly erode trust in the platform.
A cheap test that catches most problems
Export twenty random unified profiles with their linked source records and read them like a human. Not counts, not dashboards — twenty actual people. If you can look at all twenty and say “yes, that is one person and those are the right values,” your ruleset is probably fine. If you hesitate on three of them, you have found your next week of work.
What good looks like
A healthy identity setup is boring in a specific way. The ruleset is short enough to explain in one meeting. Every message-facing attribute has a written reconciliation decision. There is a documented list of test individuals that someone re-checks after each change. Segment counts move for reasons the team can name. And when a personalisation bug appears, the first question is “which rule produced this value” rather than “who broke the email.”
None of that requires heroic data engineering. It requires deciding the rules deliberately, early, and in writing — before the segments, the activations and the reports get built on top of them.