Why Your HubSpot Salesforce Integration Is Lying to You
Your HubSpot Salesforce sync is running but the data is wrong. RevBlack breaks down the 6 failure modes behind broken integrations and what actually fixes each one.
A broken HubSpot-Salesforce integration rarely announces itself. The sync is technically running. Records are moving between systems. Marketing is sending campaigns. Sales is logging activity. Leadership is getting reports. RevBlack has audited dozens of dual-stack environments where every one of those things was true - and the data was still wrong.
The reports are wrong. The campaigns are firing on bad data. The MQL that marketing flagged as high priority has been sitting in a sync queue for six hours while the prospect goes cold. Nobody finds out until someone pulls the thread. A rep says "I had no idea marketing had already emailed this account three times." A VP asks why the pipeline numbers in HubSpot and Salesforce do not match. That is when it becomes clear: the integration has been lying for a while.
This article covers the six specific failure modes RevBlack sees most often, why each one happens, and what actually fixes them.
Why Is the Native HubSpot Salesforce Connector Not Enough?
The native HubSpot-Salesforce connector is a sync tool - a good one for basic use cases - but it was not designed to handle custom fields, complex workflows, and automation running in both systems simultaneously without deliberate configuration.
Most teams turn it on, map the obvious fields, and assume the rest will sort itself out. It does not. The six failures below are what happens when the integration is installed rather than designed.
Failure 1: Why Do HubSpot and Salesforce Handle the Same Person Differently?
HubSpot and Salesforce use fundamentally different record models for people - and connecting them without resolving this upfront creates broken records that compound silently over time.
HubSpot has one record for a person: a Contact, associated with a Company. Salesforce has two: a Lead and a Contact. A Lead is a pre-conversion record with no company attached. Once converted, it becomes a Contact tied to an Account, and the original Lead is retired.
When these systems are connected without deciding how to handle this upfront, the same person can exist in Salesforce as an incomplete Lead with no company, an orphaned Contact with no Account, or both. Multiply that by thousands of contacts and the sales team is working from broken records while the marketing team wonders why company data is not showing up.
The fix is a decision, not a technical one: how does the organization want to handle Leads vs. Contacts in Salesforce, and how does that map to how HubSpot creates records? That decision has to be made before the integration is configured. For the full architectural decision on Leads vs. Contacts in Salesforce, see the data model differences guide.
Failure 2: Why Do Two-Way Sync Rules Corrupt Data?
The native integration offers three sync options for each field: always use Salesforce, always use HubSpot, or two-way where the most recent value wins. Two-way sounds right - in practice, it means whichever system wrote to a field last wins, regardless of whether that write was correct.
A real example: a Salesforce admin marks a contact as "Customer" after a deal closes. Meanwhile, a HubSpot workflow re-enrolls that contact in a nurture sequence and resets their status back to "Lead." Two-way sync fires. Salesforce now shows a paying customer as a Lead. Marketing keeps nurturing someone who already bought. No error message. The data just changes, and nobody knows why.
The right answer is deliberate field-level ownership: some fields should always be controlled by Salesforce, some by HubSpot, and some should not sync at all. For how to configure field-level ownership correctly, the guide to preparing for the HubSpot Salesforce integration covers sync direction decisions before go-live.
Failure 3: Why Are Salesforce Validation Rules Silently Blocking the Sync?
Salesforce lets admins set rules that reject records missing required information - for example, every Lead must have a Lead Source, or a disqualified lead must include a reason. These rules are useful. The problem is when HubSpot tries to sync a record that does not meet them, the sync fails quietly.
No alert. No notification. The record sits in HubSpot getting nurtured, invisible to the sales team in Salesforce, while pipeline numbers silently diverge between the two systems.
This is one of the most common reasons HubSpot and Salesforce show different numbers. It is not a reporting problem. It is records that never made it across because of rules nobody reconciled when the integration was set up. For a full diagnostic of every sync error type and the fix for each one, see the HubSpot Salesforce sync errors playbook.
Failure 4: Why Does the Same Person Exist as Multiple Records in Both Systems?
HubSpot identifies duplicates by email address. Salesforce can match on email, name, phone, or custom logic. When the two systems do not agree on matching criteria, the same person ends up as multiple records - one from a HubSpot form, one entered manually by a rep, one from a list import.
The integration does not merge these. It syncs all of them, potentially creating new duplicates in the process. The rep is calling the same prospect twice. Attribution data is split across three records. Lead score is calculated on partial information.
Deduplication is not a one-time cleanup - it requires a defined strategy for how duplicates are detected and resolved, enforced as an ongoing process. For the full deduplication sequence before and after go-live, the CRM deduplication playbook covers the match criteria and master record logic that prevents this failure mode.
Failure 5: Why Can the Sales Team Not See What Marketing Is Doing?
When a contact opens an email, fills out a form, or visits the pricing page, that activity lives in HubSpot. For the sales team to have context before they call, that activity needs to surface in Salesforce on the right record.
The native integration has limits on what activity syncs and how. Marketing engagement data often stays in HubSpot while reps in Salesforce have no visibility into it. The result: reps call into accounts cold, not knowing marketing has been warming them up for months. Or they call right after a contact unsubscribed, because that signal did not sync in time.
The fix: configure activity sync deliberately - choose only the signals that matter (form submissions, marketing email sends) and use the HubSpot Visualforce component or Timeline Embed in Salesforce so reps can see marketing engagement without flooding the task queue. Syncing every email open as a Salesforce task creates noise that reps stop reading.
Failure 6: Why Is the Sync Too Slow for Time-Sensitive Signals?
The native connector runs on a cycle, not in real time. For most data, that is acceptable. For time-sensitive signals - unsubscribes, demo requests, MQL triggers - it is not.
A rep who calls a contact 20 minutes after they unsubscribed did not make a mistake. The integration did. For high-priority signals, webhooks or middleware are needed to push data immediately rather than waiting for the next sync cycle. That is not a workaround - it is the right architecture for the use case.
What Actually Fixes a Broken HubSpot Salesforce Integration?
All six failures share the same root cause: the integration was installed, not designed. RevBlack addresses this by making three decisions before touching a single configuration.
1. Who owns what. Every field that syncs needs a designated owner - HubSpot or Salesforce. Without this, both systems fight over the same data and the most recent write wins, regardless of accuracy.
2. What can block the sync. Salesforce's validation rules and required fields need to be audited against what HubSpot actually captures. If there is a gap, records fail silently until someone notices the numbers do not add up.
3. How duplicates get resolved. Match criteria, master record logic, and what happens to duplicate records need to be defined before the integration creates its first conflict.
If you are not sure where the integration stands, start with three questions: Does the sync error count surprise you? Do pipeline numbers match between both systems? Can the sales team see marketing activity without switching tools? If any of those are broken, it is fixable - but it will not fix itself.




