Nobody gets excited about identity resolution. It doesn’t demo well. There’s no slide where you show a reconciliation rule and the room leans in. But every time I’ve seen an Agentforce rollout wobble after go-live, the root cause traces back to the same place: the agent didn’t actually know who it was talking to.
Data Cloud’s whole pitch is a unified view of the customer. Identity resolution is the machinery that builds that view. If it’s loose, every downstream capability, segmentation, personalisation, and now agent reasoning, inherits the mess.
What identity resolution is actually doing
Strip away the marketing language and it’s three steps. First, match rules decide which records across your Data Model Objects probably belong to the same person, using identifiers like email, phone, or a loyalty ID. Second, reconciliation rules decide which source wins when two matched records disagree on a field value, most recent, most trusted source, or a custom rule you define. Third, the result gets written to a unified individual profile that every other Data Cloud capability reads from.
That sounds clean in a diagram. In a real org it’s messier, because the inputs are messier. A contact-centre case system might use a work email. A marketing platform might have a personal one, captured years ago through a campaign form. A loyalty system might key on phone number and nothing else. Exact match on email alone will quietly fail to link all three, and you’ll end up with three “unified” profiles for one actual customer.
A scenario I keep seeing
Picture a contact-centre team that’s just turned on an Agentforce service agent. A customer calls in, the agent looks up the profile, and it finds one of the three fragments, the one tied to the phone number, not the one with the full purchase history sitting under the old email. The agent answers politely and wrongly, because it was never shown the full picture. Nobody wrote a bug. The match rules just weren’t tuned for how this business actually collects data.
This is the part people miss: identity resolution failures don’t throw errors. They just produce a confidently wrong answer, which is a worse failure mode than a system that visibly breaks.
Why it matters more once an agent is involved
A human service rep who gets handed a thin profile usually notices something’s off and asks a clarifying question. An agent, especially one running a scripted topic with a defined action, often doesn’t. It takes the profile it’s given as ground truth and reasons forward from there. Feed it half a customer and it will give you a confident, half-right decision.
And the stakes go up with the kind of actions an agent takes. A recommendation engine with a fragmented profile gives you a slightly worse suggestion. An agent with write access that updates a case, applies a discount, or triggers a refund based on a fragmented profile can take an action against the wrong history entirely. Identity resolution isn’t just a data quality nicety anymore. It’s the input validation layer for everything built on top of it, and I’d put it ahead of almost anything else on the checklist before an agent gets real write access.
Where this quietly breaks in practice
A few patterns show up again and again.
- Match rules left on the out-of-box defaults, never tuned against a sample of real source data before go-live.
- Exact-match-only logic on fields that are inherently inconsistent, like name or address, where fuzzy matching or standardisation would catch far more true matches.
- No ongoing monitoring of the unification rate, so a source system change six months later (a new form field, a renamed source object) silently degrades matching and nobody notices until someone complains.
- Reconciliation rules that default to “most recent wins” everywhere, even for fields where a specific system should always be the trusted source, like a billing address that should come from the ERP, not whichever marketing tool touched the record last.
- Merge and unmerge handled as an afterthought, so when identity resolution gets it wrong, there’s no clean process to split a profile back apart without losing history.
What actually helps
Start with a sample of real production-like data before you finalise match rules, not synthetic test records that are too clean to reveal anything. Pull a few hundred genuine customer records with the kind of inconsistency your business actually produces, and run your match rules against them by hand. You’ll find the gaps fast.
Be deliberate about which identifiers you trust for matching and in what combination. Email alone is rarely enough once a business has more than one channel of contact. Layer in phone, and where you have it, a persistent identifier like a loyalty number or account ID that doesn’t change when someone switches jobs or email providers.
Set reconciliation rules field by field, not as one blanket policy. Billing-sensitive fields deserve a named trusted source. Preference fields are usually fine on recency.
And treat the unification rate as a metric worth watching on an ongoing basis, the same way you’d watch API error rates or job failures. A sudden drop after a source system change is a signal, not noise.
Before you let an agent act on any of this
If you’re building toward agent write access, identity resolution deserves a review of its own before that conversation even starts. Ask what happens when the agent is handed a fragmented profile: does the topic design account for incomplete data, or does it assume a fully unified customer every time? If the answer is the latter, that’s a gap worth closing before the agent goes live, not after the first wrong decision gets escalated.
The unglamorous work pays for itself quietly. Nobody notices good identity resolution. Everyone notices the agent that got it wrong.
Leave a Reply