The goal of deduplication is not fewer records. It is fewer representations of the same reality.
A B2B data system can contain millions of records and still have a fundamental identity problem. The same company may appear under several names. The same person may exist across multiple providers, CRM records, enrichment systems, and campaign databases. A company may have a parent record, subsidiary records, regional records, and historical records that look similar but should not necessarily be merged. A contact may have changed jobs, email addresses, or titles, or appeared under different versions of their name.
The result is not simply a messy database. It is identity fragmentation — and identity fragmentation creates operational problems throughout the outbound stack: duplicate outreach, fragmented engagement history, inconsistent account ownership, incorrect enrichment, inflated account counts, conflicting attributes, unreliable scoring, duplicated campaign assignments, wasted data-provider spend, and incorrect reporting.
Deduplication is the process of determining which records represent the same entity, deciding what should happen to those records, and preserving the most trustworthy representation of that entity. It is not primarily a cleanup task. It is a data-infrastructure capability.
1. The Hidden Cost of Duplicate Data
Duplicate data is easy to underestimate because individual records often look harmless. One extra contact record does not appear dangerous. But imagine the same person exists four times across the system:
Record A: John Smith | VP Sales | john@company.com
Record B: John Smith | VP Sales | john.smith@company.com
Record C: J. Smith | VP Revenue | john@company.com
Record D: John Smith | VP Sales | LinkedIn profile
Each record may look individually plausible. Together, they create a fragmented representation of one person. The outbound system may then enrich the same person multiple times, assign them to multiple campaigns, send overlapping messages, count them multiple times in reporting, attach different signals to different records, calculate inconsistent scores, and lose historical context across the fragments.
The problem is not merely duplicate rows. It is multiple representations of the same entity being treated as different entities — and each separate treatment compounds the error downstream.
2. A Duplicate Is Not Just Two Identical Records
The easiest duplicates are exact duplicates: Acme Inc. appearing twice with identical fields. But B2B duplicates are often much harder to detect. The same company may appear as Acme Inc., Acme Incorporated, Acme Technologies, and Acme Technology Inc. The same person may appear as John Smith, John A. Smith, and J. Smith. The same role may appear as Vice President of Sales, VP Sales, VP, Sales, and VP Revenue.
Some of these are duplicates. Some may not be. Similarity is evidence for investigation, not proof of identity.
Salesforce's duplicate-management system separates the logic used to identify potential matches from the rules that determine what happens when a potential duplicate is found, and supports both exact and fuzzy matching because duplicate records are not always identical. A good deduplication system does not ask only whether records look alike. It asks what evidence suggests that two records represent the same real-world entity.
3. Duplicate Detection, Entity Resolution, and Deduplication Are Different
Three related concepts are often conflated, and keeping them distinct improves system design.
Duplicate detection finds records that might represent the same entity — which records look like potential matches. Entity resolution determines whether those records actually refer to the same real-world entity — are these records the same? Deduplication determines what the system should do when multiple records represent that entity — how should those representations be resolved? Merge or consolidation then creates a unified representation while preserving appropriate information and relationships.
RECORDS
↓
MATCH CANDIDATES
↓
ENTITY RESOLUTION
↓
DUPLICATE DECISION
↓
MERGE / LINK / KEEP SEPARATE
↓
SURVIVORSHIP
↓
CANONICAL RECORD
Finding two similar records does not automatically mean they should be merged. Each stage in this sequence requires a separate decision with its own evidence and rules.
4. Why B2B Data Produces Duplicates
Duplicate creation is often a structural consequence of how modern B2B data is collected rather than a data-entry problem. A company may enter the system through CRM creation, CSV import, data providers, enrichment providers, website forms, event platforms, partner data, acquisitions, manual research, outbound prospecting, and API integrations — each using different names, identifiers, formatting conventions, taxonomies, timestamps, and company structures.
For example: the CRM may record Acme Inc., Data Provider A may return Acme Corporation, Data Provider B may return Acme Technologies, and the company website uses acme.com. If the system treats every incoming representation as a new entity, duplication is inevitable.
Duplicate problems are therefore pipeline problems, not data-entry problems. The question is not simply how to clean the database — it is how to prevent multiple representations from becoming separate entities in the first place.
5. Exact, Near, and Fragmented Duplicates
Different types of duplicates present different levels of difficulty, and a deduplication system needs to handle all three.
Exact duplicates are records that are nearly identical — Acme Inc. appearing twice with the same fields. These are usually the easiest to detect and resolve automatically.
Near duplicates represent the same entity but contain variations: Acme Inc. versus Acme Incorporated, or Robert Alvarez versus Roberto Alvarez. These require normalization or fuzzy matching. Salesforce supports fuzzy matching for certain fields and algorithms that account for variations in names, titles, addresses, and other attributes.
Fragmented duplicates are the hardest. Record A has an email address. Record B has a job title and a LinkedIn profile. Record C has a phone number and a partial name. No single field proves the match — the system must combine evidence across all three records to establish identity. These are often where the most valuable deduplication work happens, and where automated systems are most likely to fail without careful design.
6. Account Duplicates vs. Contact Duplicates
B2B deduplication is more complicated than consumer deduplication because accounts and contacts behave differently and create different types of identity problems.
Account duplicates can arise from legal names, brand names, parent companies, subsidiaries, regional entities, acquisitions, domain changes, abbreviations, and multiple external IDs. Acme Global, Acme US, Acme Germany GmbH, and Acme Technologies may represent one company, a parent with subsidiaries, separate legal entities, or related but operationally distinct organizations. Account deduplication therefore requires understanding organizational relationships, not just record similarity.
Contact duplicates create a different class of complexity. People change jobs, titles, email addresses, and names. They have multiple professional profiles and appear in multiple source systems. They become associated with different accounts over time. Contact identity is therefore temporal — a useful representation is:
PERSON
+
CURRENT EMPLOYMENT
+
ACCOUNT
+
ROLE
+
IDENTIFIERS
+
TIME
A contact record is not simply name plus email. It is a representation of a person within a changing employment and account context.
7. Not Every Similar Record Should Be Merged
Acme Global and Acme Germany GmbH may be related. That does not mean they are the same entity. John Smith at Acme and John Smith at Beta should not be merged simply because the name matches. The system must distinguish between records that represent the same entity, records that represent related entities, and records that represent distinct entities.
SAME ENTITY?
│
├── YES → DUPLICATE → RESOLVE
│
└── NO
├── RELATED ENTITY → LINK
└── DISTINCT ENTITY → KEEP SEPARATE
The goal is not to eliminate similarity. It is to eliminate unintended multiple representations of the same entity — while preserving legitimate distinctions between related or similarly named entities.
8. Start With Identity, Not Similarity
A weak deduplication process begins with which records look similar. A stronger process begins with what identifiers and evidence establish identity.
For an account, identity evidence may include domain, external company ID, legal identifier, normalized company name, address, and parent relationship. For a contact, it may include verified email, external person ID, phone, LinkedIn profile identifier, current employment confirmation, name, and account relationship.
The strength of each identifier depends on context. A verified work email may be highly reliable for contact matching. A company name alone may be weak. A domain may strongly identify an organization but may not uniquely identify every legal entity behind that domain. Identity should be established through evidence, not inferred from whichever field happens to be available.
9. Deterministic vs. Fuzzy Matching
Deterministic matching uses explicit identifiers or exact comparisons: exact external ID, exact verified email, exact domain, exact phone, or exact account identifier. It is explainable, predictable, and often highly precise. Its limitation is that it breaks when identifiers are missing, and it misses spelling differences, formatting differences, and changed attributes.
Fuzzy matching looks for similarity rather than exact equality — matching John Smith against Jon Smith, or Acme Incorporated against Acme Inc. Salesforce supports fuzzy methods and multiple matching algorithms for fields such as names and addresses. Fuzzy matching increases candidate coverage but creates false positives: records that look similar but represent different people or companies.
Fuzzy matching should expand the candidate set for further evaluation, not replace identity judgment. Candidates identified through fuzzy matching need additional validation steps before a merge decision is made.
10. Candidate Generation and Blocking
A large data system cannot reasonably compare every record with every other record. Deduplication should first generate plausible candidates by narrowing the search space before applying detailed matching logic.
ALL RECORDS
↓
CANDIDATE GENERATION
↓
MATCH CANDIDATES
↓
DETAILED MATCHING
Candidate generation might use shared domain, similar normalized phone, similar name combined with same company, or matching external identifier. Salesforce uses match keys to narrow the records considered for detailed duplicate evaluation before applying more comprehensive matching logic.
Good deduplication does not compare everything. It reduces the search space without losing important candidates — a balance between computational efficiency and recall.
11. Match Scores Are Evidence, Not Truth
A system may calculate a match confidence like this:
Name similarity → 95%
Company similarity → 98%
Phone similarity → 100%
Overall confidence → High
That can be useful. But a score is not identity itself. John Smith with phone +1 555 1234 at Acme is a very different prospect from John Smith with phone +1 555 1234 at Beta — the same name and phone number with different account context can completely change the interpretation. A match score is evidence. The system should preserve the evidence that produced the score so that the decision is explainable and can be reviewed if a merge later proves incorrect.
12. False Positives vs. False Negatives
Every deduplication system faces two major error types with different operational costs.
A false positive occurs when two different entities are treated as the same — John Smith at Acme and John Smith at Beta are incorrectly merged. The result can be wrong account associations, corrupted engagement history, incorrect signals, wrong campaign assignments, and a permanent loss of identity distinction that is difficult to reverse.
A false negative occurs when two records representing the same entity are treated as different — the same person remains fragmented across four records. The result is duplicate outreach, fragmented engagement history, duplicate enrichment costs, inflated counts, and inconsistent scoring.
A false negative fragments identity. A false positive corrupts identity. The costs are asymmetric in different ways for different workflows, which means a deduplication threshold is a business-risk decision, not just a technical parameter. The appropriate threshold depends on how costly each error type is for the specific system.
13. When Should a Match Be Automatic?
Not every potential duplicate should be auto-merged. A useful confidence model maps evidence levels to resolution actions:
HIGH CONFIDENCE → AUTO RESOLVE
AMBIGUOUS → REVIEW
LOW CONFIDENCE → KEEP SEPARATE
Exact verified email combined with same current employer and same person identifier may justify automatic resolution. Same name combined with similar title probably should not. A mature system needs defined confidence tiers with corresponding actions — and the goal is appropriate automation, not maximum automation. Aggressive auto-merging at scale can create false-positive problems that are more expensive to fix than the duplicates they were designed to remove.
14. Human Review Is Part of the System
Ambiguous cases are inevitable in any real-world B2B data system. Rather than forcing every case into match or no-match, the system should allow three outcomes: match, review, and not match.
A review queue presents the available evidence for a human decision:
Record A: John Smith | VP Sales | Acme Inc.
Record B: John A. Smith | VP Revenue | Acme Corporation
Evidence:
- Same company domain: confirmed
- Similar name: confirmed
- Same LinkedIn profile: confirmed
- Email: different values
- Title: different values
The reviewer can then resolve the ambiguity with context the automated system cannot access. Human review is not a failure of automation. It is a controlled state for cases where evidence is insufficient for automatic resolution — and the decisions made in review can become feedback for improving future matching rules.
15. Survivorship: Which Data Should Win?
When three records are confirmed to represent the same person, a new question emerges: which values should survive in the canonical record? The answer should rarely be "keep the oldest record" or "keep the record with the most fields."
Survivorship should operate at the field level. Email might be decided by most recently verified. Phone by highest-confidence source. Title by most recently observed. Company by current employment evidence. Industry by most trusted account source. Informatica's MDM documentation describes survivorship as selecting the better version of each data value during merge, with trust and recency among the factors that determine which value survives.
Deduplication answers whether records are the same. Survivorship answers what the resulting record should say. Both are required for a correct merge outcome.
16. Build a Canonical Record Without Losing History
The output of deduplication should not simply delete the non-canonical records. That destroys information the system may need. A better result is:
CANONICAL ENTITY
├── Current Attributes
├── Source Provenance
├── Previous IDs
├── Historical Values
├── Activities
├── Relationships
├── Enrichment History
└── Resolution History
The canonical record should represent the best current understanding of the entity. But the system should still know where each value came from and what happened to the other representations. Informatica's merge process describes creating a merged record from the most trustworthy data across participating records while retaining relevant child records and relationships.
This matters because outbound systems depend heavily on history. A contact's previous campaign activity should remain accessible after duplicate resolution. A company's previous signals should not be lost. Source IDs may be required for reconciliation with external systems. The principle is: merge identity without destroying history.
17. Deduplication Is Not a One-Time Cleanup
A database cleaned today will recreate duplicates tomorrow. New records enter continuously through CRM users, enrichment providers, imports, APIs, forms, events, acquisitions, and migrations. Deduplication must therefore be continuous:
DETECT
↓
RESOLVE
↓
MERGE
↓
PREVENT
↓
MONITOR
↓
RE-DETECT
Salesforce supports duplicate detection during record creation and editing, as well as ongoing reporting and management of potential duplicates. The right mental model is not "we cleaned our CRM" — it is "we operate a system that continuously protects entity integrity."
18. Prevention Is More Valuable Than Cleanup
The cheapest duplicate is the one the system never creates. A strong ingestion flow checks for existing entities before creating new records:
NEW RECORD
↓
IDENTITY CHECK
↓
EXISTING ENTITY?
├── YES → UPDATE / LINK
└── NO → CREATE
Rather than:
CREATE → CREATE → CREATE → CREATE
↓
QUARTERLY CLEANUP
Prevention can happen at ingestion, CRM entry, enrichment, imports, campaign assembly, and account or contact creation. Salesforce explicitly separates matching rules — which identify potential duplicates — from duplicate rules — which determine whether users should be warned or blocked. Detection tells you what might be a duplicate. Prevention determines what the system should do about it before the duplicate is created.
19. The Deduplication Data Model
A deduplication system needs more than a duplicate = true flag. A useful model preserves the evidence and decisions behind each resolution:
RECORD
├── Entity ID
├── Source ID
├── Source
├── Match Status
├── Match Candidate
├── Match Score
├── Match Evidence
├── Resolution Status
├── Canonical ID
├── Survivorship Decision
├── Merge Status
├── Merge Timestamp
├── Previous IDs
└── Review Status
Possible resolution states:
UNMATCHED
↓
CANDIDATE
↓
LIKELY MATCH
↓
REVIEW
↓
CONFIRMED DUPLICATE
↓
MERGED
Or from candidate:
CANDIDATE
├── NOT DUPLICATE
├── RELATED ENTITY
└── DUPLICATE
This makes identity resolution observable and errors diagnosable. If a bad merge is discovered months later, the system should be able to answer why the records were matched, which rules were used, what evidence supported the decision, which record became canonical, which fields survived, and who or what approved the merge.
20. How to Measure a Deduplication Pipeline
A deduplication system should not be judged only by how many duplicates were removed — that metric encourages aggressive matching and creates false merges. A more complete measurement model tracks four areas.
Detection metrics include duplicate candidate rate, confirmed duplicate rate, false-positive rate, and false-negative rate. These reveal whether the matching logic is correctly calibrated.
Resolution metrics include automatic resolution rate, manual-review rate, unresolved rate, and merge success rate. These reveal whether the pipeline is handling ambiguous cases appropriately.
Data-quality metrics track duplicate rate by source, by object type, after enrichment, by market, and by ingestion channel. These reveal where duplicates are entering the system and whether prevention controls are working.
Operational metrics track duplicate creation rate, time to resolution, records affected by duplicates, duplicate outreach incidents, and duplicate enrichment spend. These connect deduplication performance to business costs.
One particularly useful metric is duplicate creation rate after prevention controls are implemented. If this falls over time, the system is not merely cleaning the database — it is preventing the problem from returning.
21. The Complete Deduplication Architecture
Putting the pieces together:
NEW RECORD
↓
NORMALIZE DATA
↓
GENERATE CANDIDATES
↓
MATCH RECORDS
↓
MATCH CONFIDENCE
↓
┌─────────────────┬─────────────────┐
HIGH CONF. REVIEW LOW CONF.
↓ ↓ ↓
MATCH RESOLVE DISTINCT
└─────────────────┼─────────────────┘
↓
RESOLUTION DECISION
↓
┌──────────┼──────────┐
MERGE LINK KEEP SEPARATE
↓
SURVIVORSHIP
↓
CANONICAL ENTITY
↓
PRESERVE PROVENANCE
↓
MONITOR
↓
PREVENT FUTURE DUPLICATES
↓
RE-DETECT
The operational logic at each stage: match to find candidates, decide based on confidence, resolve ambiguous cases through review, survive to select field-level values, preserve to retain provenance and history, prevent to stop new duplicates at ingestion, and re-detect to catch what prevention misses.
22. Entity Integrity Before Activation
Duplicate data becomes particularly dangerous when it reaches outbound execution. A duplicated contact can produce multiple campaign assignments, repeated outreach, conflicting personalization, fragmented response history, incorrect account prioritization, duplicated buying signals, and incorrect suppression states. A duplicated account can distort ICP scoring, account priority, buying-group coverage, signal aggregation, and campaign reporting.
Entity integrity must therefore exist before activation:
DATA SOURCES
↓
COLLECTION
↓
ENRICHMENT
↓
VALIDATION
↓
ENTITY RESOLUTION
↓
DEDUPLICATION
↓
CANONICAL DATA
↓
QUALIFICATION
↓
ELIGIBILITY
↓
ACTIVATION
↓
OUTCOME
The tools, providers, CRM, and enrichment sources may all differ across implementations. But the infrastructure still needs to answer the same question before any record reaches outreach: is the system acting on the entity it believes it is acting on? That is an identity problem — and deduplication is the layer that solves it.
Conclusion
B2B data rarely arrives as one clean representation of reality. It arrives as fragments. Different systems describe the same company differently. Different providers describe the same person differently. Records change over time. New sources introduce new identifiers. The same entity gradually accumulates multiple representations across the outbound stack.
A reliable deduplication system needs to identify potential matches, resolve identity, distinguish duplicates from related entities, balance false positives and false negatives, route ambiguous cases to review, determine field-level survivorship, create a canonical representation, preserve provenance and history, prevent new duplicates at ingestion, and continuously monitor identity fragmentation.
The objective is not to make the database contain fewer rows. The objective is to make the database represent reality more accurately. Duplicate detection tells you what might be the same. Deduplication determines what to do about it. Deduplication is not a one-time cleanup — it is an operating capability.
The next question is how entity integrity connects to campaign eligibility: once records are resolved and canonical, what determines whether they can be activated into an outbound motion.
Sources
Salesforce Trailhead — Improve Data Quality in Salesforce. Available at: https://trailhead.salesforce.com/content/learn/modules/sales_admin_duplicate_management/sales_admin_duplicate_management_unit_2
Salesforce Trailhead — Resolve and Prevent Duplicate Data. Available at: https://trailhead.salesforce.com/content/learn/modules/data-cleanup-fundamentals/identify-and-manage-duplicate-and-disconnected-records
Salesforce Help — Matching Criteria in Matching Rules. Available at: https://help.salesforce.com/s/articleView?id=sf.matching_rules_matching_criteria.htm&language=en_US&type=5
Google Cloud — Entity Resolution. Available at: https://docs.cloud.google.com/bigquery/docs/entity-resolution-setup
Informatica — Merge Process. Available at: https://docs.informatica.com/master-data-management/customer-360/10-3/user-guide/resolving-duplicates/resolving-duplicates-overview/merge-process.html
Informatica MDM — Survivorship. Available at: https://docs.informatica.com/master-data-management/multidomain-mdm/10-4/survivorship-guide/survivorship-overview.html
IBM — Matching Algorithms in Match 360. Available at: https://www.ibm.com/docs/en/ws-and-kc?topic=data-matching-algorithms-in-match-360
Gartner — Magic Quadrant for Augmented Data Quality Solutions (February 2026). Available at: https://www.gartner.com/en/documents/7429962
Append Diagnostic Review
// Protocol: Submit deliverability insights, system architecture observations, or technical inquiries.