RevOps Playbook: Deduplication and Identity Resolution for the HubSpot–Salesforce Integration

The fastest way to lose executive confidence in funnel and pipeline numbers is to let duplicates multiply. A duplicate contact becomes two MQLs. A duplicate account becomes split pipeline. A duplicate opportunity becomes double‑counted revenue. This playbook lays out a practical, auditable deduplication and identity strategy that works with the HubSpot–Salesforce integration and scales as you add enrichment providers and new motions.

We’ll design around four domains: identity keys, match rules, merge policies, and governance. The outcome is a data contract that preserves history, protects commercial truth, and allows controlled automation without breakage.

Identity Keys by Object

Every object needs a primary key and a small set of secondary keys that are both portable and available at creation time. Over‑engineered keys delay capture and increase error rates.

Contacts/Leads:

Companies/Accounts:

Deals/Opportunities:

Match Rules That Balance Precision and Recall

Build two tiers of matching so you can automate confidently and route edge cases to review:

  1. High‑confidence auto‑match: exact email; or exact normalized domain + exact phone for companies; or exact external ID for revenue objects.
  2. Probable match (requires human review): fuzzy name + domain; phone similarity; or address proximity for regional accounts. Use points‑based thresholds and present the top candidate.

HubSpot provides email‑based dedupe for Contacts and domain for Companies; Salesforce supports rules and matching sets. Align them by using the same normalization functions and by stamping “suspect” flags to guide SDRs.

Merge Policies and Survivorship

Merges must be deterministic. Publish survivorship rules:

  1. Contacts: keep the email that is business (non‑personal) if both exist; keep the older CreateDate for lifecycle reporting; keep the owner from the “primary” record unless the secondary has an open Opportunity association.
  2. Companies: keep the parent in your hierarchy; keep the normalized domain that matches your naming standard; merge open Opportunities and re‑parent them to the survivor.
  3. Deals/Opportunities: never merge in HubSpot alone; ensure the Salesforce Opportunity remains the source‑of‑truth and that the HubSpot Deal re‑points via the shared external key.

Audit merges by writing a merge log to a custom object or property set: Merged_At, Primary_Id, Secondary_Id, Survivorship_Notes. This turns a scary operation into a reversible and inspectable one.

Routing and Assignment with Duplicates in Mind

Routing breaks when duplicate detection is late or inconsistent. Build guardrails:

Enrichment Without Flip‑Flops

Vendors enrich at different cadences and with different schemas. Prevent value oscillation:

  1. Land vendor values in staging fields (e.g., Industry (VendorX)). Promote to canonical only if the canonical is blank or older than N days.
  2. Stamp Enriched_By, Enriched_At, and Provider to maintain lineage and support troubleshooting.
  3. Disallow enrichment from overwriting ownership, commercial fields, or lifecycle fields.

Activity, Campaign, and Attribution Safety

Merges should not erase your marketing proof or sales activity:

  1. On person merges, re‑parent activities (calls, meetings, tasks) to the surviving record and retain campaign membership.
  2. On company merges, sum campaign influence carefully. Use Opportunity association rules to avoid double counting influenced revenue.
  3. For attribution, keep first‑touch and last‑touch on the survivor. If both records have first‑touch, preserve the earlier date and store the other in an “alternate first‑touch” note for audit.

Toolchain Patterns That Help

Whether you use native integration only or add iPaaS/warehouse sync, these patterns increase safety:

  1. A pre‑create hook: before creating a net‑new record, run a match with your high‑confidence rules; if a match is found, update instead of creating.
  2. A post‑import reconciliation: after bulk loads, run a duplicate scan and queue merges; never merge in bulk without a sample review.
  3. A dedupe dashboard: show duplicates by object, by source (marketing, sales, imports), and by severity; track time‑to‑merge.

Governance and RACI

Make deduplication everyone’s job by clarifying who does what:

Review policies monthly. Share metrics with leadership so tradeoffs (e.g., holding personal domain leads) are transparent.

Success Metrics

Choose a few that actually reflect quality:

Anti‑Patterns

Avoid these quicksand traps:

FAQ

How do we handle generic or shared inbox emails?

Treat them as low‑confidence until a rep validates. Use additional keys (phone, LinkedIn, job title) to confirm identity. Consider converting to a named contact once confirmed and demoting the generic record.

Can we block personal email domains entirely?

Only if your ICP doesn’t include them. Otherwise, accept them into HubSpot for nurture but require validation before Salesforce creation. Many self‑serve motions originate from personal domains; don’t throw them away, just quarantine them.

What’s the safest way to merge large duplicate sets?

Batch by clear rules (exact email/domain). Sample 50 merges for human review before running the rest. Log all merges and recheck attribution/Opportunity association afterward with a scripted audit.

Should we dedupe in the warehouse instead?

Use the warehouse for discovery and reporting, not for operational merges. Operational systems need immediate resolution. The warehouse can provide match candidates and track survivorship history.

How do we stop enrichment from changing territory assignment?

Keep territory logic in Salesforce with explicit inputs and freeze those inputs when the record is owned. Route enrichment into staging fields and open a task if a territory‑relevant attribute changes materially.

More RevOps Playbooks from Bles Software