RevOps Playbook: Duplicate Management, IDs, and Ownership Across HubSpot and Salesforce

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.

Even with the best forms and clean imports, duplicates creep into every CRM. Without a plan, they multiply, poison routing, and break attribution. This playbook presents an opinionated approach to preventing, detecting, and merging duplicates, while establishing a stable ID and ownership strategy that keeps your HubSpot–Salesforce data lovable—and trustworthy.

What “Good” Looks Like

Clear business keys for people and accounts (email, domain) plus durable system IDs.
Automated dedupe on creation and frequent batch detection for drift.
Opinionated merge rules that preserve attribution and minimize owner thrash.
Ownership guardrails that block accidental reassignment from later syncs.

ID Strategy: The Backbone of Deduplication

IDs connect records across platforms and over time.

System IDs: Salesforce IDs for Lead/Contact/Account/Opportunity are authoritative. Store them in HubSpot properties (e.g., salesforce_contact_id).
Business keys: Email for people, domain for accounts. Use exact matches first; add fuzzy matching rules (e.g., name + company + email domain) only when confidence is high.
Cross‑system stamps: When a HubSpot Contact syncs to a Salesforce Lead/Contact, stamp the resulting Salesforce ID back on the originating HubSpot record immediately to prevent double creation later.

Preventing Duplicates at Creation Time

Prevention is cheaper than cure.

Form submissions: use server‑side checks to look up existing Contacts by email and Company by domain before creating new records.
SDR adds: provide in‑flow duplicate warnings in Salesforce (potential duplicates) based on email and name + domain; block creation unless the rep confirms intent.
Imports: run a preflight dedupe pass that tags potential matches and links them to existing IDs; import as updates where possible.

Detecting Drift Over Time

Split detection into two categories:

Exact key collisions: same email or same domain creating multiple records. These are high‑confidence merges.
Fuzzy candidates: same name + company, similar domain variants (e.g., example.com vs example.co). These require caution and human review.

Schedule a weekly job to surface candidates, grouped by confidence band, and route to operations for approval.

Merge Policy and Attribution Preservation

When merging, preserve historical truth.

Surviving record: choose the record with the most Salesforce links and recent activity as the “survivor.”
Field precedence: for profile fields, prefer non‑blank values and newest timestamps; for lifecycle dates, keep earliest milestone dates (first MQL date).
Attribution: keep the earliest first‑touch and the most recent last‑touch; union campaign memberships; re‑calculate influenced opportunities if your tooling supports it.

Ownership Rules That Don’t Surprise Reps

Owners shouldn’t change because of unrelated data syncs.

Lock owner on acceptance: once a lead becomes SAL, disallow owner changes from bulk updates and enrichment syncs.
Reassignment window: only permit automated reassignment during a defined early window (e.g., first 24–48 hours) or when the record re‑qualifies after dormancy.
Merge‑time owner: keep the owner from the record with open tasks or active opportunities. If neither has activity, use territory rules.

Handling the Lead/Contact Duality

If you use Salesforce Leads, implement cross‑object dedupe:

Before creating a Lead from HubSpot, search Salesforce for existing Contacts by email. If found, attach activity to the Contact and skip Lead creation.
At conversion, check for an existing Account by domain and an existing Contact by email. Merge rather than creating duplicates.

Company and Account Hierarchies

Parent–child structures complicate dedupe. Aim for:

One Account per billable entity; children represent brands or regions as needed.
Domain map: a normalized table that associates known brand domains to the parent account.
Merge rules that never destroy parent relationships; re‑parent children before merging.

Tooling and Automation Patterns

Automatic exact‑match merges for email and domain when confidence is 100% and no conflicting owners or opportunities exist.
Human‑in‑the‑loop review for fuzzy matches with a one‑click decision from an operations queue.
Merge scorecard that logs each decision: why merged, survivor, fields preserved, and the rules used.

Governance and Auditability

Record provenance: stamp merged_from_ids and store a merge transcript.
Exception logs: reasons a merge was skipped (open case, conflicting owners, multi‑brand domain) to improve rules over time.
KPIs: duplicate rate by object, time to merge, owner churn rate post‑merge.

FAQ

Is email still a safe dedupe key?

Mostly yes, but handle shared or role‑based mailboxes carefully. Use email + name + company for higher confidence and allow reps to override with justification.

Should we ever auto‑merge fuzzy matches?

Only when the score crosses a very high threshold and there are no owners or open deals. Even then, log everything for rollback.

How do we prevent duplicates when multiple inbound sources fire at once?

Use idempotent creation patterns: check for existence by business key, then create with an external ID so retries don’t create new records.

Who should own the merge process—Ops or Sales?

Operations should own rules, tooling, and reporting. Sales can propose merges, but Ops approves, merges, and audits outcomes.

How do we reconcile Opportunities after a contact merge?

Re‑associate the person to the correct Account and opportunity team. If your attribution depends on campaign membership, re‑run influence calculations.