Identity Resolution and De‑Duplication: Prevent Duplicates Across HubSpot and Salesforce

Few problems destroy trust like duplicates. Two records for the same person guarantees double emails, mis‑routed tasks, and confused sellers. Duplicates at the account level fracture opportunity history, inflate pipeline, and sabotage territory rules. This playbook converges on a practical, layered approach to identity resolution across HubSpot and Salesforce so you cut duplicates at the source and keep them from creeping back.

We will define deterministic rules that are simple and effective, add probabilistic checks for edge cases, and turn merges into a safe, reversible operation. Expect fewer manual fire drills and cleaner dashboards within weeks.

Why Duplicates Happen

Duplicates rarely come from one source. They accumulate from:

Preventing duplicates requires guardrails at capture, alignment on matching rules, and fast remediation loops before errors fan out to downstream systems.

Deterministic Matching Rules

Start with the simplest rule set that covers 80% of cases.

Normalize inputs—lowercase, trim, and strip punctuation where appropriate—before matching. Small consistency rules prevent big messes.

Probabilistic and Provider‑Assisted Matching

For the 20% of edge cases, layer probabilistic matching:

Flag potential matches to a review queue. Do not auto‑merge based on fuzziness alone. Human‑in‑the‑loop is essential for long‑term trust.

Guardrails at Data Capture

Stop duplicates before they enter the system:

Guardrails are always cheaper than large‑scale cleanups.

Merge Strategy and Lineage

Merging is not just “which record survives.” Plan for lineage:

Lineage lets you audit merges and reverse them if you discover a mistake.

Cross‑System Dedupe Policy

HubSpot and Salesforce dedupe in different ways. Define a unified policy so the two systems stay aligned:

Do not allow either system to insert a record the other considers a duplicate without logging it in an exception queue.

Monitoring and SLAs

Measure and manage duplicates like an SRE manages uptime:

Set targets and publish a simple monthly readout. When SLAs slip, review the last 10 duplicates and fix the upstream step.

Enrichment, Normalization, and Picklists

Enrichment is a double‑edged sword. It clarifies identity when used carefully and creates duplicates when it introduces variant spellings or stale domains. Normalize enriched values (company names, industries) into your canonical picklists. Reject values that are not in your allowed sets, or bucket them under “Other” and capture the raw string for later review.

Change Windows and Backfills

Large dedupe changes deserve a change window. When you introduce a new matching rule or merge policy:

Respect the operational tempo of sales. A flawless Tuesday morning matters more than a perfect algorithm.

Example Merge SOP (Illustrative)

  1. Confirm match: Verify winner and candidate via email/domain and opportunity presence
  2. Snapshot: Export both records for rollback reference
  3. Merge: Apply field precedence rules and preserve activities and campaign history
  4. Lineage: Write merged_from_ids__c, merged_at__c, and merged_by__c
  5. Cross‑system update: Mirror winner and merged IDs to HubSpot/Salesforce counterpart
  6. QA: Re‑load both systems and validate associated records and reports

Observability and Tooling Notes

Use a simple dashboard that reports:

If you use iPaaS, enable dead‑letter queues for records that fail dedupe checks so they do not silently enter production.

Training and Change Management

Teach SDRs and CSMs how to search before creating. Build short videos showing how to merge safely and when to escalate. Publish a one‑page “duplicate playbook” with examples of good and bad merges. Reward teams who keep duplicate rates low.

Playbook Example: Post‑Event Duplicate Cleanup Week

Monday starts with a CSV audit of new event leads. The team runs a dedupe pre‑flight comparing emails and domains, flags personal addresses, and maps companies to canonical domains. Tuesday focuses on deterministic merges for obvious duplicates and creating lineage for everything merged. Wednesday routes ambiguous cases to a review queue with two admins signing off before merges. Thursday mirrors merged IDs between HubSpot and Salesforce and reruns attribution to ensure campaign membership persists. Friday closes with a QA pass on top dashboards and a brief retro that adds two new guardrails to the import checklist.

This cadence keeps events from poisoning your database while the memory of edge cases is fresh. Over time, the pre‑flight ruleset improves and duplicate rates after events collapse.

Implementation Checklist

Use this list to move fast without breaking records:

FAQ

Why do duplicates spike after events and list imports?

Events have inconsistent inputs and tight timelines. Enforce pre‑flight dedupe on CSVs and publish a same‑week merge SLA after events to keep duplicates from hardening.

Should we dedupe Leads and Contacts differently in Salesforce?

Treat Leads as a staging area. Use aggressive dedupe on email and domain before conversion. On conversion, match to existing Contacts and Accounts; only create new when identity is unambiguous.

How do we recover from a bad merge?

Keep lineage: original IDs, timestamps, and user. Provide a “restore” playbook that re‑creates children (activities, opportunities) if needed. Limit restore permission to admins.

Can enrichment providers solve duplicates for us?

They help, but only with a governance layer. Providers disagree with each other and drift over time. Use them as signals, not as the sole source of truth.

What’s the minimum viable dedupe we can ship this quarter?

Email dedupe for Contacts, domain dedupe for Companies/Accounts, and a weekly manual review queue. That alone removes most pain and buys time for sophistication later.

More RevOps Playbooks from Bles Software