RevOps Playbook: HubSpot–Salesforce Duplicate Management and Identity Resolution

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.

Duplicates erode trust. They waste SDR time, distort funnel metrics, break routing, and sabotage attribution. Identity resolution—deciding which records represent the same real‑world person or company—is therefore a first‑class responsibility of RevOps. This playbook defines a pragmatic, defendable approach to preventing, detecting, and merging duplicates across HubSpot and Salesforce.

We focus on upstream prevention, reliable matching rules, transparent merge processes, and auditability. The outcome is a cleaner database and fewer operational surprises.

Identity Model and Keys

Treat identity as a model with keys and precedence. At minimum, you need:

External IDs: salesforce_contact_id and salesforce_account_id on HubSpot; corresponding external IDs in Salesforce for HubSpot mirrors if used.
Natural Keys: Email for Contacts and domain for Companies. Use them with caution and rules for shared domains and aliases.
Secondary Signals: Name similarity, phone number, job title, location, and engagement source.

Create a deterministic matching policy: first attempt exact external ID match, then exact email for contacts, then domain + company name similarity for companies. Only fall back to fuzzy matching with human review.

Upstream Prevention

Prevention beats cleanup. Put guardrails on every entry point.

Forms: In HubSpot, dedupe on email. For high‑risk forms (demo, sales contact), add real‑time checks that suggest existing matches.

Imports: Enforce templates that include external IDs and use upsert operations. Reject imports with missing required keys or dangerous picklist values.

Manual Entry: In Salesforce, require users to search before creating. Use duplicate rules that block or warn on near matches and explain why.

Integrations: Configure enrichment and other connectors to upsert by external IDs and emails, not blindly create. Log rejected creates.

Detection and Scoring

Run periodic duplicate scans with a scoring model. Combine deterministic and fuzzy rules:

High Confidence: Same external ID, or same email (case‑insensitive) for contacts; same domain for companies.
Medium Confidence: Email aliases (plus addressing, subdomains), phone match, or name similarity above threshold.
Low Confidence: Same last name and company, or similar domain without clear ownership (e.g., shared email providers).

Compute a composite duplicate score and route only high and medium to a merge queue. Log low confidence as leads for manual investigation when convenient.

Merge Policies and Survivorship

Define survivorship rules per field category so merges are predictable.

Keys and IDs: Keep the surviving Salesforce ID; associate losing IDs as aliases for audit.
Timestamps: Preserve earliest first‑touch and latest last‑touch where meaningful.
Lifecycle and Status: Keep the most advanced lifecycle and the most recent valid status; do not regress a qualified lead.
Ownership: Keep the active owner unless the losing record belongs to a more senior territory or named‑account owner, in which case escalate.

Implement merges in the master system for each entity: merge Contacts and Accounts in Salesforce if it is the master; mirror the outcome to HubSpot using external IDs. For HubSpot‑origin contacts, merge in HubSpot when appropriate and ensure the integration collapses to a single Salesforce person.

Operational Merge Workflow

Operationalize merges with a clear workflow:

Queue: Suspected duplicates appear in a prioritized queue with evidence and score.
Review: An operator confirms duplicates, selects the survivor, and edits field‑level survivorship where needed.
Execute: Merge in the master system; integration mirrors to the other side.
Verify: Post‑merge validation checks that links, activities, and campaign memberships persist.
Audit: Log the merge with surviving ID, losing IDs, actor, timestamp, and rationale.

Activity and Association Preservation

Merges should not delete history. After merging, verify that Tasks, Emails, Meetings, and Campaign Memberships remain attached to the surviving record. For Opportunities, ensure Contact Roles re‑associate correctly. If an integration cannot preserve links automatically, run a reconciliation script as part of the merge runbook.

Company Resolution and Shared Domains

Shared domains (gmail.com, university domains) are dangerous for company matching. Use additional signals: company name similarity, website, LinkedIn URL, employee count, and billing address. For ambiguous cases, require manual selection.

For multi‑brand organizations with many websites, maintain a canonical company list with all known websites and map them to a single Salesforce Account. In HubSpot, store the canonical salesforce_account_id on the Company record.

Product‑Led Identity Considerations

Product events create contacts before a sales conversation starts. Ensure product signups enforce email verification and add a unique product user ID to the contact profile. Use that ID in identity matching and to link product usage to CRM accounts. If product invitations create multiple users from the same company, prefer merging contacts only when they truly represent the same person.

Monitoring and KPIs

Duplicate rate is a key health signal. Track:

New duplicate candidates per week.
Confirmed merges per week.
Time‑to‑merge for high‑confidence duplicates.
Duplicate re‑offense rate (duplicates that come back after a merge).

Set targets and alert when duplicate creation spikes, often a sign of a broken entry point or a new integration.

Education and Change Management

Humans create many duplicates. Train SDRs and AEs on lookup best practices and the reason behind duplicate rules. Provide a simple tip sheet: search before creating, prefer updating, and escalate ambiguous cases.

Runbook: Emergency Cleanup

If duplicates explode after a change:

Freeze new creates in the offending path (form, import, integration).
Capture a sample of affected records to determine the matching failure.
Draft and deploy a hotfix for the matching rule or transform.
Run a targeted merge job with clear survivorship rules.
Review monitoring to confirm return to baseline.

Matching Algorithms That Balance Precision and Recall

Deterministic rules (exact email, exact external ID) are easy to explain and low risk. Fuzzy rules can catch long‑standing duplicates but must be used carefully. Consider Levenshtein distance or Jaro‑Winkler for name similarity with thresholds tuned per language. Combine signals: name similarity + same company domain + phone match is far more reliable than any single fuzzy test. Start conservative and expand only when operators trust the outcomes.

When testing fuzzy rules, track false positives and negatives separately. A small number of missed matches is safer than accidental merges of different people. Provide an operator preview UI that highlights why two records are considered a match, with the ability to adjust thresholds if a rule proves too aggressive.

User Training: Merging Without Losing Context

Merges feel risky to end users. Provide short training with before/after screenshots and a checklist: verify identity, choose survivor, confirm survivorship rules for lifecycle and ownership, and validate associations. Remind users that merges should preserve history and that they should report any loss of activities immediately so RevOps can investigate the rule that failed.

Post‑Merge Reconciliation

After merging, run a reconciliation job that checks:

All activities and campaign memberships now point to the survivor.
Opportunities and Contact Roles reference the surviving Contact.
Company associations remain intact and the correct Account is linked.
External IDs and cross‑references in HubSpot reflect the survivor ID.

Create a small daily report of merges and the reconciliation outcome. Investigate any failures the same day to maintain trust.

Automation Hazards After Merges

Automation that triggers on field changes can fire unexpectedly during merges. Protect sensitive workflows with conditions that ignore changes caused by a merge event flag. For example, add a hidden boolean merge_in_progress the integration sets while collapsing records; workflows should skip actions when the flag is true. This simple pattern prevents burst emails or ownership flips caused by automated listeners.

Tooling Options and When to Use Them

Native tools in HubSpot and Salesforce cover most duplicate prevention and merging needs. Add specialized tools only when scale or complexity requires them—e.g., multi‑source identity graphs or machine‑learning matchers. Integrate new tools into your identity policy: they should write external IDs, respect survivorship, and produce auditable logs. Avoid tools that create opaque IDs or that cannot export a merge ledger.

Governance Metrics That Matter

Track improvements, not just volume:

Duplicate introduction rate over time (per source path: forms, imports, manual, enrichment).
Merge cycle time from detection to resolution.
Share of merges performed automatically versus reviewed.
Post‑merge incident rate (activity loss, owner mismatch, broken associations).

Publish a monthly scorecard with a short narrative explaining spikes and wins. Celebrate zero‑duplicate weeks after large campaigns to reinforce good habits.

Case Study: Stopping a Form‑Induced Duplicate Flood

An enterprise ran a high‑traffic webinar campaign. A small change to a HubSpot form removed the email as a required field for a subset of language variants. The result was thousands of partial contacts that later collided with proper form fills, inflating SDR queues and corrupting campaign metrics. The fix: revert the form, backfill missing emails from registration records, and merge impacted contacts using a controlled script with survivorship rules. Lessons: keep form templates under change control, validate required fields automatically, and monitor duplicate spikes tied to specific campaigns.

Identity in Multi‑Brand and M&A Scenarios

During acquisitions or when operating multiple brands, shared domains and overlapping contacts are common. Introduce a brand dimension in the identity model and allow brand‑specific duplicate tolerances where business rules require separate records. After M&A, create a crosswalk table for legacy IDs and plan phased merges that protect pipeline while moving toward a unified account hierarchy.

Periodic Deep Cleans

In addition to continuous prevention, schedule semi‑annual deep cleans using expanded match rules and human review. Focus first on high‑value segments (named accounts, open opportunities). Deep cleans should include backfilled external IDs, domain normalization, and manual merges for ambiguous cases. Treat them like projects with dedicated time, owners, and clear success criteria.

Role of the Data Warehouse

Your warehouse is not the source of truth for operational identity, but it is an invaluable audit and analysis tool. Build a daily identity snapshot that lists each CRM record, its external IDs, natural keys, merge status, and relationships. Use this table to visualize clusters of near‑duplicates and to validate whether prevention policies are working. For historical analysis, keep a ledger of merges with before/after states so analysts can reconstruct past funnels accurately and confidently.

Email Aliases and Normalization

Normalize emails to lowercase and strip plus addressing when safe ([email protected] → [email protected]). Document domains where plus addressing is used for distinct mailboxes so you do not over‑merge. Maintain a table of known corporate alias domains and forwarders so that [email protected] can be recognized as the same person as [email protected] when appropriate. When in doubt, prefer human review.

Phone Numbers and Verification

Phone numbers are powerful secondary keys when normalized. Convert to E.164 format and capture country codes explicitly. Validate numbers with a lightweight verification service or rule of thumb (length, numeric, valid country code). Do not merge solely on phone match; use it as a supporting signal paired with email or domain.

Operational SLAs for Duplicate Handling

Set expectations with the business. For example: high‑confidence duplicates are merged within 24 hours; medium‑confidence within five business days; low‑confidence logged for investigation. Publish queue sizes and meet SLAs consistently. During peak events, communicate temporary extensions and the plan to catch up.

Merge Rollback and Recovery

Mistakes happen. Keep the ability to unmerge within a short window by retaining losing record snapshots and a mapping of merged associations. Define a rollback SOP that recreates the lost record with key fields, reassociates activities, and alerts affected owners immediately. Track unmerges as a metric; a high rate may indicate over‑aggressive matching rules.

Business Impact: Why Identity Quality Pays

Clean identity accelerates speed‑to‑lead, reduces wasted SDR outreach, and increases attribution accuracy. Marketing sees clearer lift by campaign; sales forecasts improve as duplicate opportunities disappear; customer success prevents awkward outreach to the wrong person. Quantify these wins—time saved per rep, response rates, and dashboard correctness—to justify continued investment in identity hygiene.

Self‑Serve Suggestions Without Surprises

Give users helpful, non‑intrusive suggestions. When an SDR opens a record, surface likely matches with clear evidence and a “request merge” button rather than auto‑merge. Queue requests for RevOps review to ensure policy consistency. Over time, as confidence grows, graduated levels of autonomy can be granted to senior users for specific, low‑risk merge types.

Governance Cadence and Scorecards

Treat identity like a standing program. Run a monthly, 30‑minute review where RevOps presents duplicate trends, root causes, and proposed rule changes. Share a simple scorecard with duplicate rate by source, merge SLA attainment, and post‑merge incident rate. Keep the conversation practical and focused on the highest‑leverage fixes.

Preventing Duplicates in Outreach and Sequencing Tools

Many duplicates originate in sales engagement tools that integrate with Salesforce and HubSpot. Configure those tools to respect external IDs, require lookups before creation, and block additions for existing participants. Standardize import flows so that CSV uploads go through the same dedupe checks as forms and APIs. Periodically audit the engagement tool’s database for orphaned records and reconcile to the CRM.

Internationalization Complexities

Names and addresses vary widely across regions. Adapt matching thresholds by locale and avoid splitting names unless required. Use transliteration carefully and favor original scripts where input systems allow it. For companies operating in multiple languages, maintain alias lists for company names (e.g., local brand names) and normalize addresses using postal standards per country. Document these rules so operators understand why the system proposes a match across differently spelled entities.

Onboarding Playbook for New Team Members

New hires should learn identity rules on day one. Provide a short module that covers keys and external IDs, how to search before creating, what to do when they find a suspected duplicate, and how merges work. Include a sandbox exercise: resolve a curated set of duplicates using the standard workflow, then review with a RevOps operator. Reinforce the message that a few extra seconds of searching saves hours of cleanup consistently.

KPI Targets and Alert Thresholds

Set clear targets so teams know what “good” looks like. For example: duplicate introduction rate below 0.5% of new records; 95% of high‑confidence duplicates merged within 24 hours; post‑merge incident rate below 0.1%. Configure alerts when daily rates exceed 2× baseline or when SLAs are missed three days in a row. Make these targets visible in team dashboards to foster shared ownership.

Checklist for New Integrations

Every new tool connected to HubSpot or Salesforce should pass a brief identity checklist:

Uses upsert semantics with external IDs where available.
Looks up by email and domain before creating records.
Does not write to protected fields (e.g., lifecycle) without approval.
Logs attempts and failures for audit.
Has a rollback plan in case of erroneous bulk writes.

Gate production access on passing this checklist. Review identity metrics in the first week after go‑live to catch issues early.

Data Stewardship Roles

Assign named data stewards in each region or business unit who serve as the first line of defense for duplicate questions and merges. Give stewards limited merge permissions and a direct line to RevOps for complex cases. Publish office hours and a simple intake form so users can report identity issues without guessing where to go, and recognize stewards for measurable improvements in identity quality.

An Annual Identity Roadmap

Identity work compounds. Plan an annual roadmap that includes deep cleans, rule tuning, integration reviews, and education. Tie roadmap items to business events—territory changes, product launches, or M&A—to ensure alignment. Share the roadmap and quarterly progress so stakeholders see identity as an ongoing capability rather than a one‑time project, with clear owners and timelines for each initiative.

FAQ

Should we enable automatic merging?

Only for the highest‑confidence cases (exact external ID or exact email). For anything else, require human review to avoid accidental data loss or ownership flips.

How do we handle different people sharing an email alias?

Do not merge. Add a flag for shared email and rely on secondary signals for routing and engagement. Encourage unique emails where possible.

What about subsidiaries and parent accounts?

Do not merge unless operationally required. Represent relationships via parent/child links in Salesforce and keep distinct Accounts when selling motions differ.

Can enrichment overwrite our cleaned values?

Guard sensitive fields. Configure enrichment to only fill blanks or write to alternate fields for review. Monitor enrichment writes and roll back noisy vendors.

How often should we run duplicate scans?

Weekly is a healthy cadence for most orgs, with daily watches for high‑volume inbound funnels. Increase frequency after large imports or territory changes.