HubSpot–Salesforce Sync Issues: A Field Guide to Diagnosis and Repair

This is a field guide to the seven failures behind the large majority of broken HubSpot–Salesforce integrations we’re asked to repair — how to spot each, the fix, and, at the end, the design principles that keep the sync boring (the highest compliment an integration can earn). A 60-second orientation first, because the architecture explains the failure modes: the native connector syncs objects pairwise (contacts↔contacts/leads, companies↔accounts, deals↔opportunities), governed by three things — an inclusion list (which HubSpot records are allowed to cross), field mappings (which properties correspond, and in which direction), and Salesforce’s own rules (validation, required fields, permissions), which the sync must obey like any other user. Most failures live in one of those three layers.

Failure 1: The sync-error backlog nobody owns

Symptom: Records missing in one system; the connector’s sync-health screen shows hundreds or thousands of accumulated errors. Diagnosis: Open the error list and group by type — you’ll usually find three or four error classes explaining 90% of the volume, not a thousand unique problems. Fix: Triage by class, not by record. Resolve the underlying cause (usually one of Failures 2–4 below), then bulk-resync the affected cohort. Then put a weekly 20-minute error review on a named person’s calendar — this single habit prevents most of this article.

Failure 2: Salesforce validation rules and required fields rejecting records

Symptom: Errors citing required fields or validation failures; new HubSpot leads never appear in Salesforce. Diagnosis: Salesforce validation rules apply to the integration user just as they do to humans. A marketing form that doesn’t collect a field Salesforce requires produces a record that cannot cross. Fix: Three options, in order of preference: collect or enrich the field before the sync attempts the record; set a defensible default; or exempt the integration user from the rule (a governance decision — document it if you take it). The wrong fix is deleting the validation rule sales relies on.

Failure 3: Picklist and property-type mismatches

Symptom: Errors on specific fields; values arriving blank or as “other”; the classic — a picklist value that exists in HubSpot but not Salesforce. Diagnosis: Compare allowed values on every mapped picklist. These drift constantly, because admins on each side add values without telling the other. Fix: Reconcile values now, then close the door: new picklist values on synced fields go through one change process covering both systems. This is field governance’s least glamorous, most frequent payoff.

Failure 4: Duplicates forking across the boundary

Symptom: The same human exists twice — as a Salesforce lead and a contact, or with two emails — and HubSpot activity lands on one while sales works the other. Diagnosis: The connector matches on email. Anything that creates records outside that match — list imports on either side, other integrations writing directly to Salesforce, reps creating contacts manually — can fork identities. Fix: Dedupe within each system first (merges sync poorly across a mess), define survivorship, then tighten intake so imports and third-party tools stop minting duplicates. Routing bugs, split activity history and double outreach all trace back here — this is the same discipline as our data-hygiene system, applied at the seam between two databases.

Failure 5: Field-overwrite wars

Symptom: A field you fixed yesterday is wrong again today. Enrichment says 200 employees; a rep typed 50; the value flip-flops nightly. Diagnosis: Two-way sync on a field that both systems (or a third tool) write, with no defined winner. Fix: For every mapped field, pick one of three modes and record it in the mapping doc: HubSpot wins, Salesforce wins, or two-way with a documented tiebreak. Fields written by enrichment tools almost always deserve a single defined writer. If you can’t say who wins a field, the sync decides for you — at 2 a.m., silently.

Failure 6: The inclusion list that’s too broad (or missing)

Symptom: Salesforce fills with junk leads sales never wanted; Salesforce record limits or license costs climb; sales stops trusting anything marketing-sourced. Diagnosis: Everything in HubSpot is allowed to cross — newsletter subscribers, competitors, students, event badge scans. Fix: Sync on merit. An inclusion list tied to lifecycle criteria (MQL-and-above, plus hand-raises) keeps Salesforce a sales system rather than a marketing archive. This decision alone often removes half the sync’s error volume and most of sales’ resentment. It also has a licensing dimension — the same database-scoping logic that governs platform record tiers applies at this boundary.

Failure 7: Latency treated as breakage

Symptom: “The sync is broken — the lead isn’t in Salesforce yet.” It arrives 20 minutes later. Diagnosis: Sync frequency, API limits and batch behavior mean cross-system latency is a real number, not zero. If routing or SLA clocks live downstream of the sync, that latency is inside your speed-to-lead whether you measured it or not. Fix: Measure the actual creation-to-availability delta. If hand-raise routing depends on the sync, either route in the system of capture or engineer the priority path so hot leads don’t queue behind batch updates. (This is failure mode #2 in our lead-routing field guide, seen from the integration side.)

Designing a sync that stays fixed

Repairs decay unless the architecture underneath changes. Four principles:

1. One page of truth. A field-mapping document — every synced field, direction, writer, and conflict winner — that a new admin could read in ten minutes. If this doc doesn’t exist, the sync’s real documentation is scattered across the memories of whoever configured it.
2. Sync on merit, not by default. Inclusion criteria tied to lifecycle stages, reviewed quarterly.
3. One lifecycle owner. Stage fields sync one direction from a designated source of truth. Bidirectional lifecycle sync is how funnels fork (we cover why in the lifecycle stages framework).
4. A named human and a weekly cadence. Twenty minutes on the error queue, monthly on mapping drift. Integrations aren’t projects; they’re small products with an on-call rotation of one. When to escalate beyond the native connector: genuinely custom objects, multi-directional flows across three-plus systems, transformation logic the connector can’t express, or volume pushing API limits. That’s iPaaS or custom API territory — worth doing deliberately rather than stretching the native sync past its design.