Every enterprise claims to have a single customer view. Almost none of them do. What they have is five versions of the customer — the CRM version, the billing version, the support version, the marketing version, and the one in the data warehouse that was stitched together three years ago and hasn’t been questioned since.
This isn’t a cosmetic problem. Identity is the join key of the entire enterprise. When it’s wrong, every report is subtly wrong, every personalization is subtly off, and every AI agent built on top of it acts on fiction with total confidence.
Why identity breaks
Identity breaks because every source system has its own opinion about who a customer is, and none of them are wrong — they’re just incomplete. The CRM knows “Robert Smith, rob.smith@email.com.” Billing knows “Bob Smith, rsmith@work.com, account 88412.” Support knows a phone number and a first name. The mobile app knows a device ID. None of these records agree, and all of them are real.
The naive fix is “just match on email.” It works until it doesn’t: shared family emails, work emails that change when people change jobs, customers with three accounts across three business units. Email is an attribute, not an identity.
Match and merge: the mechanics
Identity resolution comes down to two questions: which records refer to the same person, and what do you do about it?
Matching is the first question, and it has two flavors. Deterministic matching — same email, same phone, same government ID — is precise but misses most real-world messiness. Probabilistic matching scores the likelihood that two records are the same person based on name similarity, address proximity, shared identifiers, and behavioral signals. Good systems use both: deterministic rules for the obvious cases, probabilistic scoring for the rest, and a human review queue for the gray zone in between.
If your matching is fully automatic with no review queue, you don’t have identity resolution. You have identity roulette.
Merging is the second question, and it’s where most projects quietly fail. Merging doesn’t mean deleting records. It means linking them: every source record survives, and a golden record sits above them as the resolved view. Delete the sources and you lose lineage, auditability, and the ability to un-merge when you get it wrong. And you will get it wrong sometimes.
Survivorship: who wins
When five records disagree about a customer’s address, which one is right? That’s survivorship, and it needs explicit rules — not vibes.
The honest answer is “it depends on the attribute.” The most recent address usually wins. The legal name from the verified onboarding system beats the nickname someone typed into a support ticket. The phone number the customer used last week beats the one from 2019. Survivorship rules should be attribute-level, source-ranked, and visible — anyone should be able to ask “why does the golden record say this?” and get an answer, not a shrug.
The golden record and the 360 view
A golden record is the resolved, survivable, lineage-tracked representation of an entity — customer, product, location, supplier. The 360 view is what you build on top of it: every interaction, transaction, and touchpoint attached to one identity.
Here’s what separates real 360 views from slideware: the golden record is operational, not analytical. If it only lives in the warehouse for reporting, it’s a museum piece. The real thing feeds the call center screen, the personalization engine, the fraud check, and the agent — in real time, through APIs, with the same identity everywhere.
Identity in the agentic era
This is where identity goes from important to existential. A dashboard showing a duplicated customer is an embarrassment someone might notice. An autonomous agent acting on a duplicated customer is a machine that emails the wrong person, applies the wrong discount, or discloses one customer’s data to another — at speed, at scale, without asking.
Agents don’t have the human instinct to say “wait, this doesn’t look right.” They act on whatever identity you hand them. Every identity defect your organization tolerated in the BI era becomes an incident in the agentic era. The math changed; the tolerance can’t stay the same.
Your agents will be exactly as trustworthy as your identity resolution. No more.
What good looks like
Good identity resolution has a shape you can recognize: source records preserved with lineage, match rules versioned and explainable, a review queue for uncertain matches, attribute-level survivorship rules, golden records served operationally through APIs, and metrics — match rate, merge rate, false-positive rate — that someone actually watches.
It’s unglamorous work. Nobody demos identity resolution at a conference. But it’s the foundation everything else stands on: the 360 view, the personalization, the analytics, and now the agents. Get identity right and the rest gets easier. Get it wrong and the rest gets fictional.
The enterprises that treat identity as infrastructure will have an almost unfair advantage as agents take over more of the work. The ones that don’t will have very fast, very confident systems acting on five different versions of the truth.
— Jugal
Thanks for the comment, will get back to you soon… Jugal Shah