If you are here because records are not syncing, the numbers do not match, or duplicates keep coming back — the cause is almost certainly on this page. Each failure below is named with its real root cause and the fix, whether you implement it yourself or bring someone in.
Trusted by 500+ organizations — including B2B SaaS and technology companies running marketing in HubSpot and revenue in Salesforce with Twopir Consulting.
Diagnosis & Remediation
These are the failure modes we find, in roughly the order of how often they appear. Almost all of them originate in a default setting that was never a deliberate decision.
The integration matches on email address alone. Merge the pair without surfacing the Salesforce IDs and create dates first, or merge in the wrong system first, and the sync faithfully recreates what you just cleaned up.
A required field, a validation rule or an unmatched picklist rejects the write. The record sits in the error queue with no alert attached, and the two databases quietly separate.
Everything was set to two-way because it looked safest. Two-way means the last write wins, and the last write is usually an automation nobody remembers building.
A bulk import, a list re-score or a mass property update consumes the Salesforce API allocation. Records queue rather than sync, and sustained overuse can suspend the connection entirely.
Salesforce matches on the internal API value, not the display label. A renamed label over an unchanged value, or a stray trailing space, rejects every update against that field.
With no inclusion list, subscribers, event no-shows and job applicants arrive alongside buyers. Reps stop trusting the queue, then stop working it — which looks like a sales problem and is not.
Campaign influence is captured on the contact, the lead converts to an opportunity, and the link is gone. Marketing can prove it created leads and can prove nothing about revenue.
Mapped directly to one another despite measuring different things — funnel position versus current activity. Each overwrites the other and neither field means anything afterwards.
The integration user lacks edit rights on an object, or the profile changed during an unrelated permissions cleanup. Everything for that object stops, often without anyone connecting the two events.
Almost every Salesforce HubSpot integration failure traces back to one of three things: a decision that was never made, a failure that was never surfaced, or a definition that was never agreed. The symptoms look varied. The causes are not.
Decisions never made. Sync direction, field ownership, which records may cross, and what happens on a conflict — each has a default, and the defaults are chosen for safety of installation rather than for correctness in your business. Two-way on every field and no inclusion list are both defaults, and both are wrong in almost every environment.
Failures never surfaced. The integration is designed to keep running when individual records fail. That is correct behaviour and it is also why divergence compounds invisibly: a rejected write produces a queue entry, not an alarm. Without deliberate alerting, the first person to notice is whoever runs the quarterly report. HubSpot documents the error surface in its sync error guidance and the suspension causes in its suspension error guidance.
Definitions never agreed. Lifecycle stage, lead status, what counts as qualified, when marketing hands over. These are business agreements that get encoded as field mappings, and mapping fields whose definitions disagree simply makes the disagreement operational.
The practical consequence is that fixing symptoms individually does not hold. Merging duplicates without an identity strategy regenerates them; clearing an error queue without alerting refills it. Remediation has to reach the cause. Twopir Consulting does this work as a Salesforce Partner and a HubSpot Partner for growing and mid-market companies and for enterprise organisations. For the layer where most of these are fixed, see Salesforce HubSpot data sync; for the model that prevents them, Salesforce HubSpot architecture; and to have yours assessed, our integration services.
The most common diagnostic mistake is treating the symptom. Each row below names what you are seeing, what is really happening, and what fixes it permanently.
| Symptom | Usual root cause | The fix that holds |
|---|---|---|
| Records are not syncing at all | Integration user permissions, or the API allocation is exhausted and records are queued. | Check the integration user's object permissions first, then the API call allocation against your Salesforce limit. Set the allocation deliberately and monitor headroom. |
| Some records sync, others silently do not | Inclusion list membership, or writes being rejected by validation rules and required fields. | Read the sync error queue grouped by cause, not by count. Then reconcile the inclusion list against what sales actually needs to see. |
| Duplicates reappear after cleanup | Merging without surfacing Salesforce IDs and create dates, or merging in the wrong system first. | Surface Salesforce Contact ID, Lead ID and create date before any merge; where both records carry Salesforce IDs, merge in Salesforce first so the sync resolves the survivor. |
| A field keeps reverting | The field is set two-way and an automation on the other side rewrites it. | Assign one authoritative system for that field and set the sync rule one-way. Record the decision in the source-of-truth matrix so it is not undone later. |
| Picklist updates are rejected | Internal API values differ between systems even though the labels match. | Align internal values explicitly on both sides. Never rely on labels matching — they are not what Salesforce compares. |
| The two systems report different pipeline | Lifecycle and status definitions disagree, or attribution is lost at lead conversion. | Agree stage definitions in writing, represent them in both systems rather than mapping one native field to the other, and carry campaign association through conversion. |
| Integration suspended | Sustained API allocation overuse, frequently triggered by a bulk import or list re-score. | Recover by freeing calls, then prevent recurrence: set the allocation, monitor it, and schedule bulk operations against known headroom. |
| Reps say the CRM is full of junk | No inclusion list, so every HubSpot contact crosses regardless of qualification. | Build an inclusion list from real qualification criteria. Remember that Salesforce-created records sync to HubSpot regardless of the list. |
Every engagement here starts by measuring the damage, because the size of the divergence determines whether the answer is a repair or a rebuild.
Establish what is actually wrong and how far it has spread, before proposing anything. The measurement is what makes the remediation plan defensible internally.
Cleanup sequenced so it does not regenerate the problem. Order matters more than tooling.
Changing the settings that caused it, and recording why — so the next person does not reverse the fix in good faith.
The change that prevents recurrence. Most environments we see have no alerting at all, which is why the problem grew large enough to need us.
Remediation done in the wrong order regenerates the damage. Cleanup before prevention is the most common and most expensive sequencing error.
Read the error queue and quantify divergence. Establish whether this is a repair or whether the configuration is far enough gone to warrant a rebuild — those are different projects.
Correct the configuration causing ongoing damage before touching historical data. Cleaning up while the cause is still running is work that undoes itself.
Duplicates resolved in the correct merge order, divergent fields reconciled to the authoritative system, orphaned associations repaired.
Alerting to a named owner, allocation monitoring, inclusion list, and the source-of-truth matrix that stops the settings drifting back.
Re-reconcile both systems to prove the gap closed, then hand over the check schedule so your team can confirm it stays closed.
A North America B2B SaaS company where a home-built sync had failed silently. Nobody knew until the reconciliation quantified it.
The diagnostic surfaced three problems we did not even know we had. By the time we saw the field mapping spec, it was obvious why the previous sync had been silently corrupting data for months. What impressed us most was that every decision was documented — we were not handed a black box. We owned the system at handover.
Three automation conflicts identified and disabled before remediation began, then an Apex error-logging layer built so failures could never be invisible again.
A remediation that clears the error queue and changes nothing else buys you about a quarter.
Record-level reconciliation first. Without a number, nobody can tell whether the remediation worked or whether it needed to happen at all.
Cleaning data while the misconfiguration is still running is work that undoes itself. The order is not negotiable.
Merge order determines whether duplicates resolve or regenerate. It is the single most common reason cleanup projects fail twice.
Most environments we are called into have none. Making failure visible is what turns a one-off repair into a durable fix.
Sometimes the configuration is far enough gone that repair costs more than starting again. We say so, with the reasoning, rather than billing the repair.
The most common cause is exhausting your Salesforce API call allocation. Bulk imports, re-scoring a large list, mass property updates and large email sends all generate significant call volume; when the allocation is consumed, records queue rather than sync, and sustained overuse can suspend the connection. Recovery means letting calls free up, then preventing recurrence by setting the API call allocation in HubSpot deliberately against your Salesforce limit and checking headroom before any bulk operation. Permission and validation errors on the integration user are the other frequent cause.
Because the merge did not resolve the pair as far as the sync is concerned. The integration matches on email address only, so the fix depends on merge order and on visibility of the Salesforce identifiers. Surface Salesforce Contact ID, Lead ID and create date on the HubSpot records before merging anything; where both records carry Salesforce IDs, merge in Salesforce first so the integration links the surviving record instead of recreating the duplicate. Without prevention at the creation points as well, cleanup regresses.
Almost certainly the field is set to a two-way sync rule and an automation on the other side is rewriting it. Two-way means the most recent write wins, and automations write more often than people do. The durable fix is to assign one authoritative system for that field, set the sync rule one-way accordingly, and record the decision so it is not reversed later by someone who assumes two-way is safer.
Salesforce compares the internal API value, not the display label. Two picklists that look identical in the interface can differ underneath — a label renamed without the value changing, a trailing space, or a case difference. Every update against the mismatched value is rejected into the error queue. Align the internal values explicitly on both sides; checking that the labels match is not sufficient.
Three causes account for most of it. Lifecycle stage and lead status mapped to each other despite measuring different things, so the funnel means something different in each system. Campaign attribution not carried through lead-to-opportunity conversion, so marketing's sourced number and the CRM's disagree structurally. And records sitting in the sync error queue that one system has and the other does not. All three are architecture problems that surface as reporting problems.
Start with the sync error queue and group the entries by cause rather than counting them — eleven thousand errors is usually three problems, not eleven thousand. Then check the integration user's object permissions, then the API call allocation against your Salesforce limit. That order resolves the large majority of cases. If the errors are spread across many causes with no dominant pattern, the problem is usually the field mapping rather than any individual rule.
It depends on how much of the configuration reflects a deliberate decision. If the mapping is broadly sound and a handful of fields and rules are wrong, repair is faster and cheaper. If everything is two-way, there is no inclusion list, no documentation and no one who can explain why any setting is what it is, rebuilding against a proper specification is usually less work than reverse-engineering the current state. We give a written recommendation either way, including when the answer is repair.
Partly, and it depends on what still exists. Where the underlying campaign membership and original source data survive on the HubSpot side, association can often be rebuilt and forward reporting restored. Where the data was overwritten rather than merely disconnected, history generally cannot be reconstructed — which is why attribution design is one of the decisions worth making before it breaks rather than after.
Bring us the error queue and read access to both systems, and we will tell you what is actually happening — including when the answer is that you can fix it yourself.
Salesforce Partner · HubSpot Partner · Serving US, Canada, UK, UAE, Australia & New Zealand
