De‑Duping and Data Quality in HubSpot + Salesforce: Merge Rules, IDs, and Sync Conflict Resolution

The fastest way to lose credibility with go‑to‑market teams is to show them reports with obvious duplicates: the same person counted twice, the same company in two territories, the same deal in two stages. Duplicates are not just cosmetic—they distort routing, inflate campaign results, and make SLAs impossible to enforce. This playbook provides a practical, durable approach to deduplication and conflict resolution across HubSpot and Salesforce so your integration stays trustworthy under load.

We focus on three pillars: 1) deterministic keys and matching, 2) explicit merge execution ownership, and 3) conflict resolution rules for when both systems have something to say. With these in place, your data quality improves steadily instead of spiking and crashing with every import or enrichment change.

Deterministic Keys and Matching Strategy

Start by declaring what counts as “the same” record. In B2B, email is the best primary key for people, and website/domain is the best primary key for companies. If a person has multiple emails, you must still pick one canonical email to drive matching and dedupe. For companies, normalize domains by removing common prefixes and handling obvious redirects.

Your match strategy should be strict by default and permissive only by exception. Fuzzy match can help surface candidates for review, but deterministic keys keep automated merges safe.

Merge Ownership and Execution

Never merge the same pair of records in both systems. Pick one execution point and stick to it. Most revenue teams designate Salesforce as the authoritative place to perform merges for Contacts and Accounts because sales users live there and audit history is robust. HubSpot then ingests the chosen survivor and merges its local copy accordingly.

To support this, configure the integration so merges in Salesforce propagate to HubSpot. If a merge happens accidentally in HubSpot, do not chase a second merge in Salesforce. Instead, unmerge or re‑merge in Salesforce and let HubSpot catch up. The goal is to avoid dueling merges that create “ghost” records and broken references.

External IDs and Survivorship

Create a small set of external ID properties that never change: a Contact External ID keyed to the first seen canonical email and a Company External ID keyed to the normalized domain. For custom objects, define a natural key (like subscription ID or product SKU) and back it with a surrogate key if needed.

When two records merge, apply survivorship rules in this order: primary key and external IDs survive on the winning record; audit fields (created source, original source details) preserve the earliest trusted values; recency‑based fields (latest campaign, latest intent) take the most recent value. Publish these rules so analysts and admins can predict outcomes.

Enrichment and Precedence

Multiple systems want to enrich your data: form fills, firmographic APIs, product usage, partner referrals. If two enrichment sources can write to the same field, you need a precedence policy. An effective approach is “sales beats enrichment beats marketing,” which maps neatly onto your integration: Salesforce user inputs override enrichment; enrichment overrides HubSpot capture; HubSpot capture overrides blanks.

Express this policy in workflows and validation. If an enrichment vendor attempts to overwrite a sales‑entered title, block it. If marketing tries to update phone based on form data that fails E.164 formatting, reject it and log the attempt. Consistency is kinder than partial correctness.

Conflict Resolution and Directionality

Bidirectional sync creates the possibility of write collisions. Prevent them with clear directionality per field and a small number of conflict resolution rules. If a field is Salesforce‑owned (Lead Status, owner, territory), never allow HubSpot to overwrite it. If a field is HubSpot‑owned (Original Source, Latest Source), never allow Salesforce to overwrite it.

There are a few legitimate cases for bidirectional fields (name, phone). For these, implement “last‑write wins” only when the change passes validation and is user‑initiated. System‑initiated changes should not clobber human decisions.

Duplicate Detection and Review Queues

You cannot prevent every duplicate, but you can prevent duplicates from lingering. Enable duplicate detection natively in Salesforce with matching rules and duplicate rules for Contacts and Accounts. In HubSpot, use duplicate management to surface likely pairs. Create weekly review queues for an operations analyst to disposition. The analyst’s job is to merge precisely and to annotate odd cases for future rules.

Keep the queue small by design. If you routinely see hundreds of candidates, your matching rules are too permissive or your capture processes are too noisy.

Import Hygiene and Guardrails

Most duplicates are born during imports. Require import templates with canonical columns (email for Contacts, domain for Companies). Block imports that lack keys or contain suspicious formatting. Encourage teams to import into HubSpot when contacts originate from marketing activities, and into Salesforce when the origin is sales or partnerships—never both for the same list.

For large vendor or partner imports, run a dry‑run in a sandbox and review the would‑merge and would‑create counts. Fix before you ship.

Normalization: Titles, Countries, and Phones

Normalization is not glamorous, but it is the cheapest and most effective way to make dedupe safer. Normalize titles to title case, strip salutation noise, standardize country and state names, and enforce E.164 on phone numbers. Run normalization closest to the point of capture (HubSpot forms/workflows) and again before writing to Salesforce. When Salesforce users edit, apply validation rules and a post‑save normalizer via flow or trigger.

Audit Trails and Explainability

When something looks wrong, a human will ask, “Why did this change?” Make sure you can answer. For merges, capture the pair, the survivor, the user who executed, and key property deltas. For enrichment, log the source and timestamp of each write. For normalization, annotate the rule that changed the value. You do not need a full data lake to do this; a few well‑chosen history fields and a tiny audit object go a long way.

Measuring Data Quality

Treat data quality as a performance metric. Create a simple scorecard with three measures: duplicate rate, merge cycle time (from candidate creation to merge), and invalid value rate (failed validation). Trend it weekly and share it with marketing and sales leadership. When the scorecard is visible, behavior improves.

Incident Response: When Things Go Wrong

Despite good design, incidents happen: a bad import floods the system, an enrichment rule runs amok, or a bidirectional field gets misconfigured. Your response should be predictable. Freeze writes to the affected fields, gather a diff of what changed and when, and prepare a reversible script or workflow to restore known‑good values. Communicate clearly about what happened, what was affected, and how you will prevent a recurrence.

Runbooks for Common Scenarios

Create lightweight runbooks for the duplicate scenarios you see most often:

Two Contacts with the same email in different systems: merge in Salesforce, let HubSpot catch up.
Two Companies with different names but the same domain: pick the better record based on completeness; preserve external IDs and Opportunities.
A Contact converted to a Contact + Account in Salesforce but still a standalone person in HubSpot: map to the Account via domain and backfill relationships.

Runbooks reduce decision fatigue and accelerate cleanups.

Governance and Stewardship

Data quality is not an IT project; it is a revenue discipline. Assign explicit stewardship: one person responsible for dedupe cadence, one for import hygiene, one for enrichment policy. Meet monthly to review the scorecard and exceptions. Publish small improvements often rather than waiting for a “big bang” cleanup.

FAQ

Should we enable bidirectional sync for email and phone?

Yes, with guardrails. Allow human edits from either system, but block system‑initiated overwrites and enforce validation so junk cannot clobber good data.

Is it safe to let HubSpot merge records?

Prefer Salesforce as the merge execution point for Contacts and Accounts. If a merge occurs in HubSpot, do not repeat it in Salesforce manually; perform the correct merge in Salesforce and let the integration reconcile.

How do we pick a survivor during a merge?

Use keys and completeness. Keep the record with the longest, cleanest history and the best identifiers. Preserve external IDs and original source fields, then apply recency for last‑touch fields like latest campaign.

What about custom objects like subscriptions or entitlements?

Define a natural key (subscription ID) and mirror it into both systems. Avoid duplicate creation by blocking inserts without a key and by validating uniqueness before write.

How often should we review duplicate candidates?

Weekly is a good cadence for most teams. If volume is low and stable, you can move to biweekly. If volume spikes, investigate capture or import changes—do not simply merge faster.