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

Published by Bles Software, a custom software and AI company based in Yehud-Monoson, Israel, building web apps, AI agents and API integrations for clients in Israel, the US, the UK and the EU.

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:

Primary key: email (lowercased and trimmed). If the email is blank or personal, mark the record as low‑confidence until confirmed.
Secondary keys: phone (E.164 normalized), LinkedIn URL, and a compound key of first + last + company domain.
Cross‑system keys: Salesforce Ids in HubSpot and HubSpot Ids in Salesforce; protect from editing.

Companies/Accounts:

Primary key: company domain (normalized; strip www, lowercase, collapse known variants).
Secondary: legal name + country + state/region; D‑U‑N‑S or other registry IDs if present.
Cross‑system: external IDs for lookups in orchestration and warehousing.

Deals/Opportunities:

Primary: a generated external key shared across systems.
Secondary: (Account Id, Name, CloseDate, Amount) used for duplicate detection heuristics only.

Match Rules That Balance Precision and Recall

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

High‑confidence auto‑match: exact email; or exact normalized domain + exact phone for companies; or exact external ID for revenue objects.
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:

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.
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.
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:

Hold marketing‑created Contacts with personal email domains in a review queue; after SDR validation, release to Salesforce.
If a probable match is found, route to the account owner’s SDR/AE automatically with an “existing account suspected” flag; do not auto‑create a net‑new account.
For PLG trials, pre‑validate domains and enforce SSO for business email to reduce duplicate person records.

Enrichment Without Flip‑Flops

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

Land vendor values in staging fields (e.g., Industry (VendorX)). Promote to canonical only if the canonical is blank or older than N days.
Stamp Enriched_By, Enriched_At, and Provider to maintain lineage and support troubleshooting.
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:

On person merges, re‑parent activities (calls, meetings, tasks) to the surviving record and retain campaign membership.
On company merges, sum campaign influence carefully. Use Opportunity association rules to avoid double counting influenced revenue.
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:

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.
A post‑import reconciliation: after bulk loads, run a duplicate scan and queue merges; never merge in bulk without a sample review.
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:

Marketing Ops: owns pre‑create checks, enrichment staging, UTM/campaign integrity, and backfill hygiene.
Sales Ops: owns Salesforce matching rules, merge execution for Accounts and Opportunities, and owner policies.
Data/Analytics: owns warehouse survivorship, QA cohorts, and attribution sanity checks post‑merge.

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:

Duplicate rate per 1,000 records by object (weekly).
Merge time‑to‑resolution and backlog size.
Percentage of Opportunities linked to exactly one Account and at least one primary Contact.
Funnel stability: variance between HubSpot and Salesforce volumes at each stage.

Anti‑Patterns

Avoid these quicksand traps:

Driving enrichment directly into canonical fields; it flips values and breaks rep trust.
Merging in HubSpot without confirming Salesforce re‑parenting; you’ll strand Opportunities.
Using different normalization logic in HubSpot and Salesforce; matches will diverge.

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.