How to resolve duplicate records using Data Cloud identity resolution

People search this topic because they have duplicate contacts and they want them gone. They picture one remaining row, one email, one phone, the losers deleted, the CRM quieter on Monday. What they get, if they configure identity resolution and stop there, is a profile that points at the duplicates. The duplicates are still in the source. The segment can address the person once, through the profile, while a service user opens the old contact and sees the old email. Both outcomes are real. Only one of them is a merge. This product does not do the merge.

#What you get instead of a merge

The product is Data 360. Data Cloud is the previous name. Salesforce rebranded it on 14 October 2025. The behaviour is unchanged. You may still see the old name in the application and in the documentation. "While the name is new, the functionality and content remains unchanged." The rename did not add a deduplication button.

Identity resolution is the processing engine that generates unified profiles from source profile data stored in Data 360. The profile is a set of keys back to those records. Unified profiles are keys. They are not a golden record. Read that in the workshop until the word merge leaves the slide. A segment can use the profile. Service and sales still open the source record they had. Nothing has deleted the duplicate contact. Nothing has hidden it. If your success criterion is "one contact remains in the CRM," you are in the wrong system for that criterion. Stay in the CRM for that work, and come back when the sources say what you decided.

The failure mode is a ticket. "Unification did not merge the duplicates." The ticket is accurate about the duplicates and wrong about the job. Show the author the source rows the profile points at. If those rows are the right rows, unification worked. If the author needed one of them deleted, write a CRM task. Do not reconfigure the ruleset until it pretends to be a merge. It will not become one, and a looser rule will only point the profile at more rows.

#Nothing is overwritten

The engine does not pick a winning value. It does not override existing data while it unifies profiles. Two emails remain two emails, on their source records. The profile points at both. "Most recent," "most complete," and "sales said this one" are survivor policies. They belong in a document a person signs, and in a CRM update that person is accountable for. They are not a hidden feature of the unify step. If a slide says Data 360 will choose the best phone number, replace the slide before the workshop ends. The best phone number, if you need one on the CRM contact, is chosen in the CRM. After that choice, the next ingest shows Data 360 the records you kept. The profile follows the sources. It does not lead them.

Last-write-wins is the policy people try to smuggle in, because it sounds automatic. It is wrong when the latest write was a normalisation job, a list import, or a sync that touched every row and changed a timestamp. The quieter email, edited by the customer last month, loses to a job that ran this morning. That is not a better phone number. It is a clock. If you want recency, define which system's edit counts as a human edit, and apply it in the CRM. Do not ask the profile to infer it.

Read a sample before you believe a ruleset. Take twenty profiles that point at more than one source row. List every email and every id. If a shared inbox or a switchboard number glued unrelated people together, the rule is wrong. Narrow the rule. Do not add a post-step that overwrites the losers. There is no such step, and building one in a formula "just for the segment" creates a secret survivor the CRM does not agree with. You will then have three versions: the two sources, and the formula. The agent that gets grounded on the formula will say the secret one. Ground facts you can point at in a source.

Consent makes the quiet failure specific. A false link does not average two flags into a yes, but a segment that reads only one of the flags will behave as if it had. If the profile points at two people, the activation has to see both assertions or refuse the row. A link is not a signature. The person who opted out does not opt back in because they were matched to someone who opted in.

Under-matching and over-matching are not symmetrical. Under-matching leaves the same person as several profiles. It is visible. Someone complains the agent cannot see an order. You loosen the rule with evidence. Over-matching points one profile at two people. It is quiet. The profile looks healthier, because it has more attributes filled in. Nothing on a count distinguishes it from a correct match until one person is shown another's history, or a suppression on one silences the other, or consent recorded by one is treated as if the other had agreed. A wrong link is a data exposure, not a quality nit. Agree the tolerance with whoever owns privacy risk before the rule is loosened, not after a complaint.

#The CRM job, stated separately

Deduplicating the CRM is a project with its own owner. Define the survivor. Which record remains. Which fields copy across. Which child records reparent. What happens to activities, files, and open cases. How consent is kept at the stricter value rather than copied from the survivor if the survivor is the looser flag. Test it on a sample the business reads, including a household and a shared inbox. Then run it in the CRM, where users will live with the result.

Only then should Data 360 see the outcome, as source data. If you unify first and merge later, the profile was relating records you intended to destroy. Rebuild the unify from the records that remain. Do not keep a profile that points at deleted ids and call it resolved. Deleted ids in a profile are a stale key ring. They will confuse the next person who samples the output, and they may confuse an activation that still has the old identifier.

Also separate accounts from people. Duplicate accounts are an account hierarchy problem: parent, billing entity, territory, and the duplicate from an old import. Running a person match across them will not collapse two legal entities, and it may attach the wrong buyers. Fix the account key in the CRM if the account is the thing that is duplicated. Then map people to the account id you kept. A domain guess is not that fix. It glues subsidiaries and public mailboxes to the wrong name unless a sample has already killed the idea.

The moment a switch from an older platform makes this argument urgent, the same distinction holds. The old tool may have sold a survivor. This one will not honour that sale. What you lose, and what you must rewrite, is the switch from a legacy CDP. Do not import the old survivor story with the new name on the slide.

#Rules you can explain

Use the fewest match keys that a sample supports. A customer number both systems actually populate is a better rule than a pile of fuzzy comparisons you cannot explain to an auditor, or to the customer whose record was linked. Fuzzy rules have a place only after the exact key is understood, and only with a sample of the false matches written down. A false match does not delete data. It still puts the wrong person in a segment, which is enough harm for one rule to be retired.

Publish the rule in plain language next to the ruleset. "Same CRM id" is a rule. "Likely the same human" is a wish. Revisit the rule when a new source arrives. A rule that was safe on CRM contacts can be unsafe the day you add a source full of shared mailboxes or reissued identifiers. Treat the new source as a change to identity resolution, not as a simple addition. Re-run the pairs you labelled as must-not-match before it goes live. The labelled set is the regression test. Without it, loosening is a guess, and guesses fail in the direction of more links, because more links look like progress.

Zero copy is federation, not a latency promise, and it does not merge records in the external store either. You can connect data using zero copy data federation and leave the bytes where they are. The profile can point at a federated row. It still will not pick a winning email out of that row and stamp it over the CRM. If you needed a latency figure for a live match decision, measure the query. Do not assume federation is fast because you avoided a copy, and do not assume it is a deduplication feature because the row is visible.

Tableau Next does not replace Tableau. A chart of "duplicate rate" will display whatever your rule did. It will not merge the rows, and it will not tell you the link was correct. The help page says you can expand Data 360 using Tableau or Tableau Next. Use the tool someone already opens, and spend the time on the sample of twenty profiles instead of on a new surface. The sample is the control. The chart of a bad rule is a confident picture of the wrong people.

#A modest outcome you can check

The outcome to aim for is small enough to verify. Profiles that point at the right source rows. Source rows unchanged. A separate, owned plan if the CRM itself must end up with fewer records. A sentence for the rule. A sample on a calendar, because sources change shape and the match moves without an error.

Read down the last column before you approve a design that says "and then the duplicates are gone." They are gone only in the CRM row, and only after the survivor job. Data 360 will keep telling the truth about whatever you leave in the sources. If you leave both emails, the truth is both emails. That is the product working.

The decisions around the rule, how strict is strict enough, which attribute is allowed to contribute a key, who owns the ruleset when the match moves, are cheaper before anything downstream has used the unified identifier. They are the identity half of getting Data 360 right the first time. Do them before you celebrate a count. The count is profile keys. It is not contacts removed.