What is Identity Resolution?

Identity resolution asks a narrow question: do these two records refer to the same real person? A Telegram conversation with “Maya” and a contact card for Maya Chen might be related, but a shared first name does not settle it. If an independent email thread contains her full name and the same project, the case becomes stronger. Evidence and conclusion are different things. The U.S. Census Bureau’s record linkage standard calls for criteria for a valid link, accuracy checks, and manual review where appropriate.

The question matters when information arrives from separately managed sources. A company may have a CRM record, a calendar attendee, a support contact, and a message sender. Each source can be internally consistent while describing the same person differently. The point is to make a connection usable without pretending the sources were born with a shared person key. IBM’s master data guidance describes people carrying different identifiers in different systems.

Consider an investor who appears on an attendee list as “M. Chen,” emails from a fund address, then messages from a personal account. If those entries remain separate, a colleague may miss the earlier meeting. If they are joined to a different Maya Chen, the colleague may disclose a private fundraising update to the wrong person. One error produces an incomplete view; the other changes what the record says about a human being. That distinction should guide every later decision.

Communication systems identify accounts for their own purposes. They do not issue a universal person key. Telegram allows a public username while a participant’s phone number remains hidden; its FAQ also says a username is optional and can be removed without ending existing conversations. A contact saved from that conversation may therefore have a handle but no number. A separate address book entry may have the number but no handle.

On X, the visible username is mutable. X says changing it leaves existing Direct Messages in place and makes the old username available to someone else. Its username guidance draws an important line: a handle can find an account today, but cannot establish a permanent identity link by itself. If an old handle is assigned to a new owner, a stored handle alone can point at the wrong person.

Ordinary life creates more variation. Someone may use a personal and a work email, change jobs, have two phone numbers, or share a family line. A source may know only the company address; another may know only the personal number. “Alex Kim” at a shared office number could mean the person who booked a meeting or a colleague at the same front desk. The question is whether the records point to the same person, not whether some text looks alike.

The source matters too. A name supplied directly in a conversation differs from a name copied out of a spreadsheet. A role mailbox such as sales@ identifies a function, and a group chat identifies a shared setting as well as individual participants. Treat each as a clue with a known scope. If you cannot tell who supplied a value or when, the safest answer to a proposed match may be “I do not know yet.”

Deterministic matching applies an explicit rule: for example, two records share a verified customer ID issued by the same organization. The result is only as reliable as the key and the rule. Matching two rows on an exact display name is deterministic as a method but weak as proof, because names are shared. The Census linkage standard calls out linking variables, standardization, and criteria for valid links because “exact” does not automatically mean “correct.”

Probabilistic matching weighs several imperfect clues and estimates how likely a pair is to describe one person. Similar names, a common organization, and matching context can justify a review even when no field proves the case. A Census Bureau study comparing methods found that text and probabilistic approaches can raise linkage rates, while some text comparisons can reduce accuracy. That result describes its study data, not a promised CRM performance figure.

Neither label tells you what a product should do with a candidate. A deterministic rule is unsafe if it treats a shared office number as a person key. A probabilistic estimate can usefully order a review queue without authorizing a merge. Two “Sam Rivera” cards with the same employer might be worth inspecting soon; two cards with a verified ID from one issuer may need less investigation. Either method can still require human approval before combining private histories.

Ask three practical questions: what evidence produced this suggestion, what happens when I accept it, and how can I correct it? Those matter more than whether the vendor says “AI matching.” The Census Bureau’s 2024 review treats linkage as assigning records to coherent groups, not merely making isolated pair decisions. An accepted pair can change the meaning of a larger group.

A missed match leaves two records for one person. A false match joins records for different people. Both matter. A missed match may hide the last conversation from a follow-up view; a false match may put one person’s private history next to somebody else’s details. The effect depends on the workflow. A newsletter list may send an awkward greeting; a relationship workspace may surface a private note or prompt a reply based on the wrong conversation.

There is no universal price for either error. A missed match might split a sales team’s follow-up across two cards; a false match might attribute one investor’s confidential note to another. The right tolerance belongs to the workflow and the data being joined. The Census standard calls for acceptable error rates and manual evaluation of automated links. That is a better rule than declaring every duplicate cheap or every wrong join impossible to repair.

Imagine an “A. Patel” on Telegram and an “Asha Patel” in a customer spreadsheet. The email domain matches a company mentioned in chat, but two employees there share the surname. Accepting the match would put the chat history into a team-visible customer record. Leaving them separate for now costs a little search time. The possible harm of a wrong join is larger, so asking Asha or checking a direct identifier is reasonable.

A high percentage of combined records can look impressive while hiding false joins. A very cautious system can look accurate while leaving useful relationships split. Sample accepted and rejected suggestions, especially common names, shared numbers, and changes of employer. The goal is a record you can act on with confidence, not the largest possible count of combined profiles.

A merge combines records into a survivor. A link can present several source cards together while preserving separate cards. Apple Contacts gives a concrete example: its Mac guide says cards from different accounts can be linked into one displayed contact while each account card remains. Its separate merge guide describes combining duplicate cards within an account. These are different operations even when the screen looks similar.

A golden record is the preferred consolidated view of an entity across sources. It is an industry term, not a promise that every field is perfect. IBM uses it for a person assembled from source data, with a survivorship rule choosing what remains when sources disagree. If an old spreadsheet says Maya works at Company A but a current email says Company B, a useful view shows current information while retaining the history that explains the old value.

Survivorship concerns displayed fields after a merge: which name, address, phone, owner, or status wins? HubSpot says the primary record generally supplies property values, with exceptions including secondary contact emails and lifecycle stage. Its merge guide shows why identity and field choice are separate decisions. Two records may unquestionably belong to one person while their preferred email still requires judgment.

Reversibility is a design goal to ask about, not an automatic property of identity resolution. Apple’s linked cards can be unlinked under its Contacts guide. HubSpot says a completed record merge cannot be unmerged. A unified display, a linked pair, and a CRM merge can all appear to reduce two cards to one while providing different recovery options.

Start with the consequence. If accepting a suggestion only groups two cards for your own viewing, the risk differs from a merge that changes team-visible history. Read what will be combined. Then inspect both records in their original context: who sent the message, which account it came from, who else was in the conversation, and whether a shared company, phone, or name could belong to several people.

Look for a contradiction before accepting. Two cards may have the same name but overlapping calls with different people, different employers, or distinct account owners. A contradiction should stop a merge even when weak clues agree. Conversely, a direct exchange in which someone supplies a new number may explain why otherwise different records belong together. That explanation is more useful than a confidence number with no visible evidence.

A message recipient is not always the owner of a contact card. A company line may be answered by several employees; a group thread contains many participants. When one participant changes jobs, the old company relationship does not become a different human. Candidate review should preserve source context. Apple’s linked contacts model provides an example of one view that retains account-specific cards.

For a team, agree on a small review rule: approve only when a direct account, number, or explicit introduction connects the records; otherwise leave the suggestion pending and note what would settle it. This is a workflow recommendation, not a claimed platform rule. The Census standard similarly includes referral criteria for cases needing clerical review instead of forcing every candidate into an immediate yes or no.

Contact fields and conversation history have different consequences. If two address book entries are linked, you might see one name and two phone numbers. If two relationship histories are combined, search results, summaries, notes, and follow-ups may all use the new identity. A mistaken join could make a promise from one person appear to be a promise from another. A careful review therefore includes a real thread from each side, not only profile headers.

Groups add another dimension. A group message has a sender and a setting. Suppose a founder says “I can introduce you” in a three-person project group. The statement belongs to that founder, but the surrounding discussion also belongs to the group. A useful relationship view should retain enough context to tell who offered and to whom. This is a principle for judging a record, not a claim about any product’s storage design.

Access needs separate review. A personal conversation and a company contact record may have different audiences. A correct identity match does not by itself authorize every teammate to read every conversation. Identity, permission, and context are separate decisions. If you cannot see which source supplied a private note, ask whether the team should combine the views at all. The Census standard requires documentation of linkage work; a practical CRM test is whether a reviewer can understand what changed and why.

Use a person you know on two channels for a trial. Compare the original threads, review the proposed match, approve only after checking, and then inspect search and the contact summary. If the combined view attributes a group exchange to the wrong person, resolve that before the team depends on the result.

The immediate benefit is context at the point of action. You can open a contact and see that the WhatsApp reply follows a Telegram introduction, or that a document request belongs to someone you met last month. This is useful only if the view gives you a way to check the underlying conversations. A summary that states a conclusion without a traceable event may be quick to read and hard to trust.

It also helps with ownership. If a colleague hands over a relationship, a confirmed contact view can distinguish “we spoke last week” from “a person with the same name spoke last week.” That sounds small until the next action is sending a deck or arranging a meeting. The record should make it easy to inspect the decisive event, such as the message where the person gave a new email address.

Time changes what a correct view should display. Suppose a buyer used a company email in January and a personal number after changing jobs in June. The two routes may belong to one person, but a reply to the old company address could now reach an assistant or fail. A reliable record shows the older route as part of the history and makes the current route clear for the next action. If nobody has confirmed which route is current, the record should leave that uncertainty visible instead of silently choosing whichever field was imported last.

A golden record still has limits. One person can have distinct roles, confidentiality expectations, and changing details over time. One identity does not mean one universal audience or one eternally correct job title. IBM’s master data discussion distinguishes matching from survivorship rules; use that distinction when a contact appears correctly linked but a displayed field looks stale. Correct the field and its source rather than breaking a valid identity link.

The most useful outcome is not a perfect diagram of every account. It is an answerable everyday question: “Is this the same person I promised to follow up with?” If the system can show the supporting conversation and let you hold an uncertain candidate for review, it helps without hiding the doubt that matters.

Pantheon brings supported Telegram, WhatsApp, iMessage, and X Direct Messages beside contact and work records. As of November 2026, a cross-channel identity match is a suggestion for you to inspect and approve. If one person writes from Telegram and later from X, compare the conversations and confirm the person before treating them as one relationship. The value is putting the conversation and next action in the right person’s context while leaving the identity decision visible.

If your job is a one-time address book cleanup, see cross-channel contact deduplication. If your question concerns what a relationship workspace does with confirmed history afterward, see Relationship OS. Those are separate decisions from defining the identity itself.

The first shortcut is treating a matching display name as verified identity. X explicitly lets people change usernames, and Telegram makes its public username optional. A name or handle should start a review, not end it. A second mistake is approving a pair without inspecting the larger group. If A joins B and B joins C, all three may appear as one person even when A and C contradict each other.

The third mistake is assuming “merge” means “undo.” HubSpot explicitly says its record merges cannot be unmerged; Apple documents a different link and unlink path. Read the action’s recovery rule before clicking. Finally, do not let a golden record hide a field conflict. Two verified accounts can belong to one person while carrying different current job titles or preferred email addresses. Settle the attribute separately from the identity.