Matching Logic That Actually Works When Two CRMs Use Different Customer Identifiers
Normalize first, then match in layers, and keep every merge reversible.
Reliable CRM data quality for M&A integration requires a sequence of complementary layers. When two CRMs use different customer identifiers, records must be normalized before exact matching, probabilistic scoring, and graph-based resolution can link them reliably. The resulting identities need evidence trails and reversible merges so that broader coverage does not come at the cost of uncontrolled false matches.
Why matching breaks when two CRMs share no common identifier
Structural identifier divergence breaks matching even when data entry is correct. The same customer enters each CRM through a different channel, and no foreign key was created to connect the records. Both records may be right within their own systems. Yet neither system has enough information to tell that the other record is for the same customer. An acquisition brings those records together but leaves the connection between them missing.
A customer’s identifiers also vary legitimately across channels. A webinar registration may include a personal email, while a sales CRM has a work email, a point-of-sale system has a loyalty ID, and a website knows the customer by a cookie. Each system sees only a subset. The records may overlap only in part because of how they were collected, even if both sources are sound.
That fragmentation reaches beyond duplicate outreach into the systems consuming the records. AI agents and personalization workflows act on the profiles they get, so when identities stay disconnected, the inputs they get are incomplete. Braze’s identity resolution guide explains that AI-driven personalization depends on complete, accurate profiles to operate at the individual level. Because no single identifier reliably bridges both CRMs, the matching architecture needs complementary layers applied in sequence.
Why normalization must come before any matching attempt
Exact comparison operates on stored values. An email stored as “USER@Example.com” will not equal “user@example.com” under a case-sensitive comparison, even when both refer to the same address. The mismatch happens before identity inference can help. Lowercasing emails, trimming whitespace, and stripping display-name wrappers give both systems a common representation. Without that foundation, even strong shared identifiers can appear absent.
Phone numbers need E.164 formatting, which turns +1-800-555-0100 into +18005550100 and strips extensions for matching. Names need lowercasing, punctuation removal, and common-abbreviation expansion, while remaining candidates for fuzzy comparison. Company comparison keys should remove legal suffixes while preserving original values, allowing “Acme Inc” and “Acme Corporation” to become candidates. Addresses need component parsing and consistent standards before street numbers, street names, cities, postal codes, and countries can be compared.
Where raw PII cannot move between systems, both sides should hash consistently normalized values, such as a lowercased, trimmed email using SHA-256. Hashing does not repair different inputs. If deterministic match rates remain unexpectedly low, inconsistent casing or phone formatting may be the cause. Adding a more complex scoring model would leave that upstream defect unresolved.
Deterministic matching: what it reliably resolves and where it stops
Deterministic matching comes first because it resolves exact agreements with the highest confidence available in the stack. It compares normalized records against a ranked set of shared identifiers, including hashed email, E.164 phone numbers, loyalty or order IDs, and any CRM-assigned user ID passed between systems. Braze defines this approach through known identifiers such as emails, phone numbers, login credentials, and external user IDs. The comparison itself requires no similarity inference. Its reliability nevertheless depends on the quality of the chosen key.
Exact agreements are not equally strong evidence of identity. A shared work email is a stronger anchor than a phone number used by a family or business line, so the engine should rank signals by strength. Each confirmed link should include the field that matched and the timestamp. That evidence supports later audits and correction. A merge without its supporting evidence is harder to challenge when conflicting information appears.
Coverage ends where shared exact keys disappear. A buyer who registers for a webinar with a personal Gmail address and enters the sales CRM under a work email remains unmatched through email equality alone. Both records can be right and fully normalized. The appropriate output is therefore a set of confirmed links plus an unresolved residual, with normalized fields intact for the next layer.
Probabilistic matching: scoring weaker signals when no shared key exists
Probabilistic matching evaluates that residual by treating field agreements and disagreements as evidence. The Fellegi–Sunter record linkage model, published in the Journal of the American Statistical Association in 1969, formalizes weighted comparisons whose contributions sum to a match score. An agreement receives more weight when it is more diagnostic of shared identity. Disagreement can push the score the other way. The logic can also be expressed as estimating the probability of a match given the observed signals.
The useful evidence extends beyond exact identifiers. Normalized first and last names support fuzzy comparisons, although nicknames, transliterations, and abbreviations weaken them. Company-name similarity helps in B2B matching, while job title provides corroboration. Postal code plus street number is more diagnostic than comparing an entire address string. Partial phone agreement is weaker than full E.164 equality, and behavioral signals are more relevant when a CRM includes web-event data.
Weights need calibration against the actual CRM data. A common first name such as “John” provides less evidence than a rarer combination of fields because unrelated records frequently share it. The acceptance threshold then expresses a business tradeoff. Lowering it reduces missed links but increases false merges, while raising it protects precision at the expense of coverage.
The right balance depends on how much each kind of error costs. Missed links sustain duplicate outreach, wasted sales effort, and fragmented AI inputs, while a false merge can be corrected if it remains flagged, reviewable, and reversible. Rejecting all probabilistic links is therefore not automatically safer. Even after scoring is calibrated, some records have little direct evidence or have useful connections that show up only through other records.
Transitive and graph-based resolution for indirect connections
Graph-based resolution addresses connections that a two-record comparison cannot see. If record A matches record B by email, and B matches C by phone, the chain A → B → C can connect A and C even when they share no field. The intermediate record supplies the bridge between them. This is an architectural change from pairwise scoring because the decision now depends on relationships across multiple records.
An identity graph represents records as nodes and matches as weighted edges. In a two-CRM integration, the bridging record may exist in neither CRM. A marketing automation platform or support ticket system may overlap partially with both, providing the connection that a direct comparison misses.
Those connections require limits on how confidence propagates. Deterministic links receive high weights, while high-confidence probabilistic links receive lower weights and weak inferences require additional corroboration before extending identity claims. Otherwise, one doubtful connection can join unrelated records. Every edge therefore needs provenance describing the evidence behind it, because a disproved link cannot be rolled back reliably if its role in the cluster is no longer known.
How do you deduplicate customer records when merging two CRMs after an acquisition?
The cascade follows Stage 0 → 1 → 2 → 3 → 4, moving from standardized inputs to persistent identities. Stage 0 normalizes every inbound record and applies consistent hashing where cross-system PII transmission is restricted. Stage 1 compares ranked exact identifiers, starting with hashed email, then phone, then loyalty or order ID. Once matches are confirmed, they leave the unresolved pool with high-confidence links. This preserves the speed and precision of exact matching where it is available.
Stage 2 scores the unresolved records using weighted field agreements and disagreements. Pairs above the high-confidence threshold are linked, those in a middle band enter review or wait for graph context, and those below remain unlinked. Human review belongs in that middle band. It concentrates effort on the uncertain pairs most exposed to false merges.
Stage 3 adds the confirmed and high-confidence links to the identity graph. Transitive resolution finds connections that pairwise comparison missed, and cluster-level merge rules decide which field values to keep when they conflict. Graph context can strengthen or weaken uncertain links. Identity linkage and field selection are separate decisions, because even after records are found to describe one customer, teams still have to choose which conflicting attribute to keep.
Stage 4 assigns a stable customer ID to each resolved cluster and records the evidence for every edge. That record includes the matching field, method, confidence score, and timestamp. Provenance is part of the operational output. Without it, a later correction may require reconstructing why records were joined before the merge can be undone.
Where each layer breaks down and what to do when it does
A low deterministic match rate on fields expected to overlap points first to normalization. Mixed casing, missing country codes, or legal and trade names that differ may still be in the data after ingestion. The corrective action belongs upstream of the matcher. Teams should check field distributions, find common variants, and add normalization rules to cover them before making scoring more complex. Those rules need to be kept up to date as new input patterns appear.
With shared business emails, role addresses such as info@company.com, or contact emails assigned to the wrong person, an exact key may point to more than one entity. Before using a field as a deterministic key, teams should check that it is unique within each CRM and quarantine non-unique values to prevent mass false merges.
Probabilistic failures appear as clearly different people being linked or clearly identical people remaining separate. Excess false merges can indicate a low threshold or excessive weight on common values such as “David”. Too many misses can mean the threshold is high or too many fields are missing. Calibration requires a labeled sample from the actual data. Field weights and thresholds should then reflect both observed signal quality and the business cost of each error type.
Graph failures appear as oversized clusters containing different people, sometimes called the “super-node” problem. A weak edge has been allowed to propagate identity across a chain. The fix is to restrict propagation to edges above a defined confidence floor and require two or more independent signals before accepting a cluster-extending link. One weak connection must not determine an entire cluster. More automation cannot compensate for that structural mistake.
The same caution applies to LLM-assisted deduplication. Automation does not establish that a matching decision is correct, and scaling a flawed rule multiplies its errors. Continuous monitoring should track match rate, merge rate, cluster-size distribution, and false-merge rate. These measures help locate the failing layer rather than treating every error as a general data-quality problem.
Keeping resolved identities reliable as records change over time
A correct match can become stale when its supporting data changes. People change jobs, email addresses, and companies, so a work-email anchor may disappear while another CRM acquires a new address. Static matching cannot maintain that connection indefinitely. The cascade needs active re-evaluation so that changed records can reconnect through new anchors. Until then, a record may depend on weaker probabilistic evidence.
Other changes affect more than one link at a time. An acquisition or company rename can disrupt account matches based on company name or email domain across an entire cohort. Phone reassignment creates the opposite risk by preserving an apparently exact key after its owner changes. The old link must then be revoked. New duplicates also need to enter the existing customer cluster without introducing unrelated records.
Monitoring must keep going after the first matching run because records keep changing. Deduplication rate, enrichment completeness, field-standardization completeness, and cluster stability show whether the resolved data remains usable as inputs evolve. Braze describes identity resolution as a journey from data unification through profile resolution to real-time activation. That continuing use requires a live pipeline.
A new deterministic signal may contradict an older probabilistic inference, requiring the system to separate records previously joined. Every merge should be reversible with its full evidence trail. Clean rollback, without manual reconstruction of the pre-merge state, is what allows broader matching coverage to remain governable as customer records change.
