Identity resolution in Salesforce Data 360 (formerly Data Cloud) links records about the same customer from different sources into one unified profile. A ruleset holds two kinds of rule: match rules, which decide which records belong to the same person, and reconciliation rules, which decide which value wins when those records disagree.
This guide explains how each part works, what has to be in place before rules run, and how to design and test rules on your own data. For the full implementation path, see our Data 360 implementation page.
What does identity resolution do in Data 360?
Identity resolution is the step that turns many partial records into one profile. A customer might exist as a Sales Cloud contact, a commerce shopper, a service case contact and a marketing subscriber, each with slightly different details. Identity resolution decides which of those records are one person and builds a single profile from them.
Trailhead's unified profiles unit puts it simply: identity resolution rules "tell Data 360 how to find relationships between data to create the unified individual." Salesforce's Data 360 page describes the aim as matching and resolving customer identities "across devices, channels, and anonymous sessions" into one living profile.
The rules live in a ruleset. Trailhead's map and unify unit says a ruleset "contains both match rules and reconciliation rules about a specific object, such as 'Individual'."
What has to be in place before identity resolution runs?
Identity resolution works on mapped data, so it depends on the two steps before it. If either is weak, the rules have nothing reliable to compare.
- Data streams. Each source lands in a data lake object (DLO) with its original structure. Trailhead's connect and transform unit notes you can create formula fields within a data stream and use batch or streaming transforms to clean data, which is where phone formats, casing and obvious junk values should be fixed.
- Mapping. DLO fields are mapped to data model objects (DMOs). Identity resolution compares individuals and their contact points, which Trailhead defines as unique pieces of data such as a phone number, email address or mailing address. If an email field is not mapped to the contact point object, no rule can match on it.
A common reason for poor match rates is not the rules at all. It is a source whose identifiers were never mapped, or were mapped from a field your teams stopped using years ago.
How do Data 360 match rules work?
Match rules define, in Trailhead's words, "what data must match for two or more source profiles to be consolidated" into one unified profile. Each rule has one or more criteria, and a rule is met only when all of its criteria are. You can have several match rules, each giving records another chance to match.
| Method | How it compares values | Typical use |
|---|---|---|
| Exact | Data must match precisely, without typos or alternative formats | Last names, customer IDs, loyalty numbers |
| Fuzzy | Allows similar matches, accommodating typos or slightly different spellings | First names, where nicknames and typos are common |
| Normalized | Matches the same information regardless of formatting; available for email, phone and address | Phone numbers and emails entered in different formats |
Trailhead's example rule combines a fuzzy first name, an exact last name and an exact email address. That pattern is a sensible start: a strong identifier (email) plus a name check that stops two people who share an inbox from merging.
Because every criterion in a rule must match, strict rules miss real matches and loose rules merge different people. Several narrower rules usually work better than one broad rule. For example, one rule on name plus email, another on name plus normalized phone, and a third on a shared customer ID where your systems hold one.
How do reconciliation rules choose which value appears?
Once records are matched, they will often disagree: two phone numbers, three spellings of a street, different birth dates. Reconciliation rules, Trailhead says, "determine the logic for data selection when the same field has different values" across matched records. They can be set at object level and at field level.
| Rule | What it selects | When it fits |
|---|---|---|
| Last Updated | The value that was most recently updated | Fields customers change, such as a mobile number or preferred name |
| Most Frequent | The value that occurs most often across the linked records | Fields where one outlier source is likely wrong |
| Source Sequence | The value from the source you rank as most trusted | Fields one system owns, such as billing address from ERP or legal name from a verified onboarding system |
Reconciliation does not throw data away. Trailhead notes that "even if a value isn't selected for the unified profile, all unique data is still stored." That matters for audit and for consent, because the original values stay traceable to their source.
What does a unified profile contain?
Trailhead is precise about this: "The unified individual by itself is not the unified profile." The unified profile is made up of two objects working together:
- Unified individual. Contains the reconciled data from all linked individuals: the single name, email and phone the rules selected.
- Unified link individual. The joining point between the source records and the unified individual, so you can always see which records formed a profile.
Unified profiles are mutable. Trailhead says they update and improve in accuracy as source data changes and new sources are processed, and profiles can be added to or removed from a unified profile as identity resolution runs again. Segments, calculated insights and Agentforce grounding then read from these profiles, so every error in identity resolution flows into each of them.
How should you design and test identity resolution rules?
Rules are easy to configure and hard to get right. This is the approach we use on Data 360 projects:
- List the identifiers each source really holds. Not the fields that exist, but the ones that are populated and trusted. A field filled in 30% of records cannot carry a rule on its own.
- Decide the business view of "one customer". For B2C, a person. For households or B2B, decide early whether people at the same address or company should stay separate, because email and address rules will otherwise pull them together.
- Start narrow, then widen. Begin with strong rules such as exact email plus name, check results, and add looser rules one at a time.
- Test on known records. Build a sample of customers your teams know well, including tricky ones: shared family emails, name changes, two people at one company. Compare unified profiles against that list after each change.
- Set reconciliation by field, not by habit. Agree with each data owner which system wins for each important field, and use source sequence where one system is the owner.
- Watch consent. Trailhead's consent module notes that consent in Data 360 is tied to each contact point, and a new email address does not inherit consent given for the old one. Unifying records does not merge their consent, so activation must still check consent per contact point.
If you want to try this on one use case first, our Data 360 Quickstart builds and tests one ruleset on your real records.
Frequently asked questions
What is identity resolution in Salesforce Data 360?
It is the Data 360 process that links records about the same person from different sources into one unified profile. A ruleset holds match rules, which decide which records belong together, and reconciliation rules, which decide which value appears when those records disagree.
What is the difference between match rules and reconciliation rules?
Match rules decide whether two or more source profiles are the same person, using exact, fuzzy or normalized criteria. Reconciliation rules decide which value to show on the unified profile when matched records hold different values, by last updated, most frequent or source sequence.
Does identity resolution delete or overwrite source data?
No. Trailhead says that even if a value isn't selected for the unified profile, all unique data is still stored. The unified profile links back to source records through the unified link individual object, and it updates as source data changes.
Which fields can use normalized matching?
Trailhead says normalized matching is available for email, phone and address. It matches the same information regardless of formatting, so differently formatted phone numbers or email addresses can still match.
Why are records not merging in Data 360?
Usually because no single match rule has all its criteria met: a rule only matches when every criterion is satisfied. Check the mapping to contact point objects first, then the rule criteria. If records merge but show the wrong values, look at reconciliation rules instead.
Talk to a Data 360 architect
Techila Global Services is a Salesforce Summit partner, headquartered in Frisco, Texas. Share your sources and the customer view you need, and we will review how identity resolution should work for you.