Data Cloud Identity Resolution: One Profile Your Agent Can Trust

Identity resolution is the step where Data 360 decides that the Maria Santos in your web forms, the M. Santos in your billing system, and the maria.santos@ address in your email tool are one person. Get it right and every downstream thing works: segmentation, insights, and an AI agent that knows who it is talking to. Get it wrong in the generous direction and you merge two people who share a household email, then send one of them the other's account details. This guide covers the mechanics and the judgement.

Why this is the step that matters

Every other Data 360 capability sits on top of this one. Calculated insights compute over unified profiles. Segments target them. Retrievers ground on them. An agent asked "what did this customer buy" gets whatever identity resolution decided that customer is.

So the failure modes are worth stating plainly:

• Under-matching leaves one person as several profiles. Your agent sees a third of their history and answers from it confidently. Lifetime value is understated. The customer repeats themselves and concludes you do not know them.
• Over-matching merges two people into one. Now you have a privacy incident rather than a data quality issue, because someone can be shown information belonging to another person.

Under-matching is embarrassing. Over-matching is reportable. That asymmetry should drive every decision below, and it is the reason we start conservative and loosen deliberately.

How identity resolution works

The process runs on a schedule and has three parts.

1. Matching. Match rules identify which source records refer to the same entity. Each rule is a set of criteria. Records that satisfy any rule are linked into the same group.
2. Reconciliation. Once records are grouped, something has to decide which value wins for each attribute. Three sources say the phone number is different; reconciliation rules pick one.
3. Unification. The result is written as a unified profile, with link objects that record which source records contributed to it. Those links matter: they are how you trace a value back to its origin when someone disputes it.

Two properties of the matching step are worth understanding, because they explain most surprises:

• Criteria within one rule combine with AND. A rule requiring first name, last name, and postcode requires all three.
• Rules combine with OR. If you have five rules, satisfying any one of them links the records.

That second point is where over-matching comes from. Every rule you add makes matching more generous, never more strict. A ruleset with many permissive rules will merge aggressively even if each rule looked reasonable when you wrote it.

One clarification that prevents a common misunderstanding. A unified profile is not a golden record, and identity resolution never overwrites your source data. Salesforce describes the unified profile as a key ring holding a key to each contributing source record. Reconciliation decides what the unified view shows; the underlying records are left exactly as they were. That is reassuring for data owners, and it also means fixing a bad value at source is still your job.

What has to be true before you start

Identity resolution operates on harmonised data. If you have not mapped your sources to the data model properly, matching will fail in ways that look like rule problems but are not.

• Sources are mapped to the same data model objects. Individual for people, contact point objects for emails, phones, and addresses.
• Contact points are modelled as contact points, not left as fields on the individual. Matching on email works by comparing email contact points, so an email sitting in a custom text field is invisible to it.
• Party identification is populated where you have it. Loyalty numbers, membership identifiers, government identifiers, and customer numbers are the strongest match signals you will ever have, because they were assigned rather than typed.
• You know your data spaces. Identity resolution runs within a data space. Records in different data spaces do not unify with each other, which is usually the point.

Spend the time here. A ruleset built on badly mapped data cannot be tuned into working.

Designing match rules

Match rules combine a set of criteria with a matching method per attribute.

Matching methods

• Exact. Values must be identical. Correct for identifiers.
• Normalized or standardized. Values are cleaned before comparison, which handles case, punctuation, and formatting differences. Correct for email and phone, where the same value is written many ways.
• Fuzzy. Similar values match. Appropriate for names, where you want Robert and Bob, or Katherine and Kathryn, to link. Never appropriate for identifiers, because a fuzzy match on an account number is a defect.

A rule ladder that works

Order your thinking from strongest to weakest signal, and build rules accordingly:

Start with the top rows only. Measure. Add a weaker rule, measure again. This is slower than writing eight rules at once and far cheaper than unwinding a bad merge.

Name alone deserves its own warning. In any dataset of reasonable size, there are multiple real people called Maria Garcia or David Smith. Matching on name alone will merge them, and it will do so silently.

Platform limits that change how you design

Four documented limits that rarely appear in write-ups and each of which can bite you quietly. Check them against the current Data 360 limits page, since these move.

• A match rule reviews about 500 combined characters. If the values being compared by a single rule sum to more than that, some are truncated during matching, and Salesforce warns this can produce incorrect matches. Long address strings plus long names get you here. Keep individual rules lean rather than piling five fields into one.
• Source records above roughly 15 KB are skipped silently. No error, no match, no profile. If a set of records mysteriously never unifies, check their size before you touch the rules.
• There is a ceiling on how many source profiles unify into one profile, in the region of 50,000. Salesforce's own note is blunt: large profiles usually mean poor data quality or match rules that are too broad. Treat any profile approaching this as a defect, not a large customer.
• Roughly 10 match rules per ruleset and 10 criteria per rule, with a small number of rulesets per primary object per data space. This is a useful constraint, because it stops you solving a data quality problem by adding a twelfth rule.

The first two are the ones worth remembering. Both fail silently, and silent failures are the expensive kind.

Over-matching: the expensive failure

These are the specific patterns that cause it. All of them are common in real data.

• Shared household email. One address used by two spouses. Matching on email alone merges them into one person. Requiring a name component alongside the email fixes most of this.
• Role addresses. info@, admin@, office@, noreply@. These appear on hundreds of records and will chain them all together. Exclude role addresses from matching entirely.
• Placeholder values. test@test.com, 555-555-5555, unknown@unknown.com, a date of birth of 1 January 1900. Every legacy system has them, in volume, and each one is a bridge between unrelated people. Find them and exclude them before your first run.
• Shared organisation phone. A main switchboard number on every contact at a company. Phone alone merges the entire company into one individual.
• Family members at one address. Two people named the same as a parent, at the same address. Name plus address matches them. Add date of birth where you hold it, or accept that you will need a name suffix comparison.
• Empty values treated as equal. Confirm how your rules handle nulls. If blank matches blank, records with sparse data will merge wholesale. This is the single nastiest version of the problem because it targets your worst-quality records specifically.

The practical defence is a short exclusion list built from your own data. Query your sources for the most frequently occurring email addresses and phone numbers before you build any rules. The top of that list is your exclusion list, and it takes an hour to produce.

Reconciliation rules: choosing the surviving value

Once records are grouped, reconciliation decides the value on the unified profile. The available approaches:

• Last Updated. The value from the most recently updated record wins. Good default for things that change: address, phone, employer, marketing preference.
• Most Frequent. The value appearing across the most records wins. Useful where repetition indicates correctness, such as a name spelling.
• Source Sequence. You rank the sources most to least preferred, and the highest ranked source that has a value wins. Correct where one system is genuinely authoritative.

You can set a default and then override per attribute. Do the per-attribute work, because a single blanket rule is almost always wrong somewhere.

How to reason about it: for each attribute, ask which system has the strongest claim to be right.

One more caution on Last Updated: it depends on the timestamp you feed it. If a nightly integration rewrites every record, everything from that source looks freshly updated and always wins reconciliation regardless of whether anything changed. Check what your last-modified values actually mean before relying on them.

Rulesets, and why you may want more than one

A ruleset is a named collection of match and reconciliation rules that produces a unified profile. You can run more than one, and there are legitimate reasons to.

• Individual versus household. One ruleset unifies people. Another groups people into households on shared address. Different questions, different answers, both valid.
• Different confidence for different uses. A conservative ruleset for anything where a wrong merge is a compliance problem, such as service and support. A more generous one for marketing analytics, where a small error rate is tolerable.
• Business unit boundaries. Often better handled by data spaces, but rulesets can play a part.

The discipline: know which ruleset each downstream consumer uses. An agent grounded on a generous marketing ruleset can show one person another person's data. If you only maintain one ruleset, make it the conservative one, and accept slightly worse marketing numbers as the price of not having that conversation.

How to test a ruleset properly

Most teams run identity resolution, look at the total profile count, decide it seems plausible, and move on. That is not a test. Do this instead.

1. Build a known-answer set first. Pick 30 to 50 real cases, decided by people who know the data: pairs that must match, pairs that must not, and the awkward ones like the two spouses on one email. Write down the expected outcome before you run anything.
2. Profile your match keys before the first run. Count the most frequent emails, phones, and names. Anything appearing hundreds of times is a placeholder or a role address. Exclude it.
3. Check the size of the largest profiles. Sort unified profiles by the number of contributing source records. A profile built from 400 sources is not a person, it is a bridging failure. This one query finds most over-matching in minutes.
4. Look at the collapse ratio. If a million source records become 300,000 profiles, ask whether you truly have that much duplication. Compare against a manual estimate from a sample.
5. Verify your known-answer set, including every must-not-match case. The must-not cases are the ones that matter.
6. Inspect reconciled values on real profiles. Pick profiles that combine several sources and confirm the surviving values are the ones you would have chosen.
7. Re-run the whole check after every rule change. Rules interact through transitivity, so a change that looks local is not.

The largest-profile query in step three is the single highest-value diagnostic in this whole area. Run it every time.

What this means for your agent

Connecting this back to AI, because that is why most organisations are here.

When an agent grounds on a unified profile, it inherits every decision above. Under-match and the agent sees a fragment, then tells a customer their order does not exist. Over-match and it discusses one person's records with another. The second scenario is the one that ends the project.

Two practical safeguards worth building in:

• Identity verification before disclosure. Put it in the subagent instructions for any agent that discusses account specifics. Do not rely on the profile alone to establish who you are speaking to.
• Ground the agent on the conservative ruleset, and know which one that is. This is a specific configuration choice, and nobody will notice it is wrong until an incident.

The wider design picture is in the Agentforce and Data Cloud reference architecture, and the grounding mechanics are in RAG with Data Cloud retrievers.

Design checklist

1. Sources mapped to the data model, with contact points as contact points.
2. Party identification populated wherever an assigned identifier exists.
3. Placeholder and role values profiled and excluded, from your own data.
4. Null handling in match rules confirmed explicitly.
5. Match rules built strongest first, added one at a time with measurement.
6. No rule matching on name alone.
7. Reconciliation set per attribute, not one blanket rule.
8. Consent reconciled from the consent system only.
9. Known-answer test set written before the first run, including must-not-match cases.
10. Largest-profile query run after every change.
11. The ruleset each downstream consumer uses is documented.
12. An owner named for data quality after go-live.

Frequently asked questions