Your HubSpot-Salesforce Sync Isn't Broken — It's Untrusted

Every RevOps team running a two-way HubSpot-Salesforce sync eventually says some version of the same sentence: "the sync is broken." It is said with the same tone people use for a car that won't start — as if there's one thing wrong, and once someone finds it, everything will run again.

That framing is almost always wrong, and it's expensive to be wrong about. A two-way sync between two independently-evolving platforms is not one mechanism. It's four or five separate mechanisms stacked on top of each other — field-value matching, association logic, deduplication, and dependent-field validation, at minimum — each maintained by different people, on different release cycles, for different reasons. When "the sync" fails, it is because one of those layers drifted, quietly, over months, until enough records piled up that someone finally noticed.

Treating that as a single incident is how sync problems become sync distrust. A team spends a week chasing what looks like one bug, patches whatever they find first, watches the error count barely move, and concludes the integration itself is unreliable. The data team stops trusting records that came through the sync. Reports get rebuilt around manual exports. The actual fix — which usually takes a day once correctly diagnosed — never happens, because nobody isolated which of the four layers was actually failing.

This is a diagnostic framework for finding out. Each layer below is independently testable, has its own failure signature, and — this is the important part — has almost nothing to do with the others. A team that runs through all four before touching a single record will spend less time than a team that patches the first thing that looks wrong.

The most deceptive sync failure is the one where everything looks identical. A picklist field shows "Marketing Qualified" on one platform and "Marketing Qualified" on the other, and the sync still throws a restricted-value error. The instinct is to assume the error is wrong, or that it's a caching issue, or to just re-save the record and hope. None of that fixes it, because the two platforms are not actually comparing what's on screen.

Most CRM-to-CRM syncs match picklist fields on an internal API value, not the display label a person sees. In a healthy setup, that internal value is a clean, human-readable string — close enough to the label that nobody notices the distinction exists. But picklists accumulate history. A field created years ago, renamed once, migrated once, can end up with an internal value that's an opaque hash or a legacy code with no visible relationship to its current label. Two platforms showing an identical label can be pointing at two completely different underlying values, and no amount of staring at the UI will reveal that.

The fix is almost always narrow once found: identify the specific picklist values throwing the error, compare their internal API values (not labels) across both systems, and either align the internal value directly or add an explicit mapping between them. It is rarely worth guessing — this is a five-minute lookup in each platform's field settings, and it's usually faster to check than to keep re-testing symptoms.

The second layer is more unsettling, because it means the sync is working exactly as designed — a downstream automation is the one making the mess. A legacy routing or matching rule, often built years before the current team arrived, can silently re-associate a record after the sync has already placed it correctly.

The clearest version of this: a domain-matching automation designed to catch obvious cases (two contacts at the same small company should share an account) can misfire on a shared institutional domain — a domain used by dozens of unrelated sub-departments, government offices, or franchise locations. The rule wasn't wrong when it was written. It became wrong when the population of domains it was matching against changed shape.

This layer is diagnosable by asking a specific question: is there any automation — on either platform — that runs on the same trigger the sync uses (record created, field updated, association changed) and could plausibly touch the same fields? If yes, test what happens with that automation temporarily disabled for a sample of affected records. If the correct association holds without it, the automation is the problem, not the sync. The fix is almost never "delete the automation" — it's narrowing its matching logic so it no longer fires on cases it was never meant to catch.

Every deduplication rule is a bet about where to place the cost of being wrong. A strict rule (exact match on multiple fields) blocks real duplicates cleanly, but it also silently rejects legitimate records that vary by even one character — an acronym in a company name, a middle initial, a slightly different email domain for a distributed organization. A loose rule lets more through, including some true duplicates, but it fails visibly: duplicate records show up in a list view where someone can see them and act.

The uncomfortable finding, once RevOps teams actually audit their duplicate rules, is usually that the strict configuration has been quietly blocking legitimate syncs for a long time — records that should have merged cleanly into an existing account instead bounced, and nobody noticed because a blocked sync doesn't throw the same kind of visible error a broken automation does. It just doesn't happen.

The practical stance: prefer duplicate rules that fail open rather than closed. Let more records through and clean up the resulting duplicates on a schedule, rather than tuning the rule so tight that legitimate records disappear into a silent backlog no one is watching. A visible cleanup queue is a known, boundable cost. A silent rejection queue is not.

The last layer is the one most likely to look unsolvable, because the error message points at the wrong field. State and province fields are usually dependent picklists — their valid values are keyed off whatever country is selected on the same record. A valid state code for one country can read as completely invalid the moment the country field itself is wrong, missing, or unmapped correctly between platforms.

This produces a specific and confusing symptom: a residual cluster of sync errors, all tied to region or state fields, that persist even after every other fix has landed. Chasing the state field directly is usually a dead end, because the state field isn't actually broken — the country value feeding it is. The diagnostic move is to check the parent field first whenever a dependent-picklist error won't clear, rather than assuming the visible error field is the one that needs fixing.

None of these four layers require a rebuild. They require running through them in order, on a schedule, before the error queue is large enough to feel unfixable. A practical audit sequence: first, pull the connector's failed-sync error log and group errors by field, not by record — patterns emerge at the field level that are invisible record by record. Second, for every picklist field showing errors, compare internal API values (not display labels) across both platforms. Third, for every association or ownership error, check whether any automation on either side runs on the same trigger and could plausibly be touching the same data — test with it disabled before assuming the sync itself is at fault. Fourth, review duplicate-rule configuration explicitly as a strictness decision, not a default setting, and check whether a "too strict" rule is silently rejecting legitimate records nobody has traced yet. Fifth, for any error on a field that depends on another field's value, check the parent field first.

Run in that order, most sync backlogs turn out to be one or two root causes wearing dozens of different error messages — not dozens of unrelated problems.

The most reassuring finding in a properly diagnosed sync backlog is how fast it resolves once the actual cause is fixed. A picklist value correction, applied once, can be followed by a single bulk reattempt against the connector's failed-sync queue — and that one action can clear the overwhelming majority of a backlog in one pass, because most of those "different" errors were the same root cause repeated hundreds of times.

That is also the trap. A bulk reattempt run before the root cause is isolated just reprocesses the same failure hundreds of times and produces the same error count back. The size of a sync backlog is not a measure of how many problems exist — it's a measure of how long one problem has been left unaddressed. Diagnose first, at the layer level, and the fix is almost always smaller and faster than the backlog makes it look.

If your team is staring at a growing sync-error queue and isn't sure which of these layers is actually failing, that diagnostic work — not another patch — is where to start. RevPal audits HubSpot-Salesforce integrations for B2B SaaS RevOps teams and fixes the root cause, not just this week's symptom.