I was wiring an Agentforce agent to Data Cloud grounding in Urla Shoes — a fictional shoe retailer that lives in a real Developer Edition org of mine — when I stopped with my hand on the keyboard.
The agent was about to answer customers using a unified profile. And that profile was assembled by match rules I had written months earlier, for a completely different purpose — a tidying exercise: fewer duplicates, better reports, a cleaner segment count. Nobody was going to speak on the basis of them.
Now something was. The rules had not changed. Their job had.
What identity resolution actually is
If the term is new to you, here is the one-paragraph version. Data Cloud — Salesforce’s data platform, more recently branded Data 360 — ingests records about people from many systems: CRM, e-commerce, web analytics, support. Those records rarely agree: different spellings, different IDs, some with an email and no phone. Identity resolution decides which records refer to the same human being and stitches them into one unified profile, following match rules you define: same email, same phone, same name plus address.
For the mechanics, I have written an introduction to identity resolution. This post assumes you have the idea and asks a different question: what changes when an agent starts talking from that profile?
Grounding turns a data decision into a speaking decision
Grounding is what we call it when an agent’s answers are anchored to real records from your org rather than to whatever the model absorbed in training. It is the biggest single reason a Salesforce agent can be trusted with customer questions: it is not remembering, it is looking things up.
But look at where the looking-up starts. The agent identifies who it is speaking with, retrieves that person’s unified profile, and answers from it. Every fact it states downstream inherits one upstream decision: which records were treated as this person. Your match rules made that decision. They now sit between a customer and what a system tells them about themselves.
Before grounding, a bad merge produced a bad report. After grounding, a bad merge produces a confident sentence spoken to a real person.
Over-merge: fluent, confident, and about somebody else
Over-merging is when your rules pull together records belonging to different people. Two customers sharing a household email. A father and a son at the same address with the same name. A shared phone number on a family account.
Now the agent holds one profile carrying two people’s lives. It will speak with total fluency about orders the person asking never placed, addresses that are not theirs, a support history belonging to someone else — and it has no way to know. From inside the conversation everything is consistent, because it is consistent with a profile describing two people as one.
This is a disclosure. Not a phrasing problem, not a hallucination, not something a better prompt fixes. One customer’s data has appeared in another customer’s conversation, and the mechanism was a data rule written for reporting reasons.
Under-merge: “I don’t believe we’ve met”
Under-merging is the opposite: rules too strict, and the same person stays split across several profiles.
The agent then greets a customer of many years as a stranger. It cannot see the order they are asking about, because that order sits on a profile it did not retrieve. It offers a first-time discount to someone who has been buying for years, and asks for details the company already holds several copies of.
This is embarrassing, it wastes people’s time, and it makes an expensive agent look foolish in front of exactly the customers you wanted to impress. But notice the shape of the harm: under-merging withholds something the customer already owns. Over-merging reveals something belonging to somebody else.
That asymmetry should decide how you tune. When an agent speaks to customers, err towards under-merging. A duplicate is a nuisance you can fix. A wrong merge is a disclosure you may never hear about.
Why every individual query still looks correct
This is what makes over-merging hard to catch, and the reason I wanted to write this post.
When something goes wrong with an agent, the instinct is to inspect the queries. So you do: take the conversation, find the retrieval, run it yourself, read the result. And the query is right. It asked for that profile’s orders and got that profile’s orders, and it stays right however often you run it.
The error is not in the query. It is in the meaning of the thing the query asked about. “This profile” no longer means “this person,” and no amount of staring at the SOQL will reveal that, because SOQL cannot tell you a row is two people wearing one name.
When every query is correct and the answer is still wrong, stop debugging the query and go and check what “one person” means in your org.
Match rules are a safety control now
Match rules used to belong to data quality, reviewed — if at all — by whoever cared about duplicate counts. They now sit on the path between a customer and a system that speaks. That makes them a safety control, and safety controls are treated differently: written down, reviewed by a second person, tested deliberately, and re-examined whenever the data sources change.
Adding a source is the moment to be most careful. A feed carrying shared household emails, placeholder phone numbers, or a generic address for an entire branch can quietly turn a rule that was safe last month into a merging machine this month. The rule did not change. The evidence it feeds on did.
Test it before an agent does
You can check this by hand. Build a small, deliberate list of people whose answer you already know.
- Known duplicates. Records you are certain are the same person. Confirm they resolve to one profile.
- Known near-duplicates. Records that look confusingly similar but are genuinely different people — the shared household email, the family phone number, the same name in the same town. Confirm they stay apart. These are the important ones, and the ones nobody builds.
- A known-clean profile. One person whose orders and cases you can list from memory. Compare the unified view against your own list, field by field.
Then do the check that matters most: pick a pair you know must never merge, write the expectation down, and re-run it after every change to a rule or a source. That is the difference between believing your resolution is safe and having checked.
Do it before an agent is pointed at the profile. A grounded agent will state whatever the profile says, calmly and in complete sentences. It is a very good spokesperson for whatever you decided a person is.
Your next step
Open your match rules and read them as though a customer were about to hear the result out loud. Then pick one pair of records that must never be merged, check that they are not, and write that pair down somewhere you will look again after your next change.
That single pair, checked on purpose, is the start of treating identity resolution as what it has become: not a tidying job, but the thing that decides what your agent thinks it knows.