A VP of Sales and a VP of Marketing sat across from me in a Series B SaaS office last quarter, both convinced the other one's numbers were wrong. Marketing's HubSpot dashboard said they had passed 412 MQLs to sales that quarter. Sales' Salesforce dashboard said they had received 280. Same company, same quarter, same people, two CRMs, a 132-lead gap nobody could explain.
The gap was not a reporting bug. It was the integration. They had switched on the native HubSpot to Salesforce connector eighteen months earlier, mapped a few fields, and assumed the rest would sort itself out. It did not. Records dropped out of the sync when a picklist value did not match. Some leads never crossed because they sat below an inclusion threshold somebody set and forgot. Duplicates piled up on the Salesforce side and overwrote good HubSpot data on the way back.
This is the most common CRM setup I see in B2B: marketing lives in HubSpot, sales lives in Salesforce, and the line between them is a sync that nobody owns. When it works, it is genuinely the best of both tools. When it drifts, you get two systems that quietly disagree and two teams that stop trusting each other's reports. Here is how the integration actually works, where it breaks, and how I set it up so it keeps telling the truth.
Why so many teams run both HubSpot and Salesforce
People assume running two CRMs is a mistake somebody will eventually clean up. Usually it is a deliberate choice, and often the right one.
The pattern goes like this. A startup picks HubSpot early because marketing needs it and it is easy to admin. The company grows, raises a Series B, hires a sales leader from a bigger company, and that leader wants Salesforce for its reporting depth, territory management, and the fact that every sales ops hire already knows it. Nobody wants to rip out HubSpot, because marketing has years of email engagement, workflows, and attribution data living there. So both stay. Marketing keeps HubSpot, sales moves to Salesforce, and the two get wired together.
I do not think that is wrong. HubSpot is a better marketing platform for most mid-market teams, and Salesforce is a more flexible sales system once you have a real ops function to run it. The mistake is not running both. The mistake is treating the connector between them as a checkbox instead of a data model decision. If you want the full cost picture of picking one over the other, I wrote a separate breakdown on HubSpot vs Salesforce total cost. This post assumes you have already decided to keep both.
An integration is not a connection. It is a decision about who owns which field.
The native connector is the easy part. The hard part is writing down which system is allowed to change each piece of data, and in which direction. Skip that and the sync slowly turns your two CRMs into two stories.
What the native connector actually does
HubSpot ships a built-in Salesforce connector on Professional and Enterprise plans. It is good software. Before you reach for anything fancier, understand what it gives you and what it does not.
The connector checks for changes roughly every fifteen minutes and syncs contacts, companies, and deals (mapped to Salesforce leads, contacts, accounts, and opportunities). It is not real time. If a rep updates a deal stage in Salesforce, expect HubSpot to catch up within the quarter hour, not the second. For most B2B workflows that is fine. For anything that needs an instant reaction, like routing a hot inbound lead the moment it converts, fifteen minutes is too slow and you handle that case separately.
Three controls decide almost everything about how the sync behaves:
Field mappings with a direction. For every mapped field you choose HubSpot to Salesforce, Salesforce to HubSpot, or two-way. This single setting causes more silent damage than anything else, because the default instinct is to make everything two-way "so both sides stay current," which is exactly how you get fields fighting each other.
The inclusion list. By default every HubSpot contact tries to sync to Salesforce. You almost never want that. You set a HubSpot active list as the inclusion segment, and only contacts on that list cross over. This is how you keep Salesforce from filling up with newsletter subscribers who will never talk to a rep.
The Salesforce integration user and its permissions. HubSpot reads and writes Salesforce as a specific user. What that user can see, HubSpot can see. Restricting it with Selective Sync stops HubSpot from pulling records it does not need, which matters more than it sounds, because of the limit I am about to get to.
The decision nobody makes: who owns which field
Here is the one page I make every team fill out before I touch a single mapping. It is worth more than any tool you will buy. For each important field, decide which system is the source of truth and set the sync direction to match.
The clean way to split it is by where the data is actually created and maintained.
Marketing-owned data flows one direction, HubSpot to Salesforce. Lead source, first touch, UTM parameters, email engagement, form submissions, original campaign. Sales does not edit these, so there is no reason for them to flow back. Sales-owned data flows the other way, Salesforce to HubSpot. Deal stage, close date, opportunity amount, account owner, forecast category. Marketing reports on these but should never overwrite them.
Only a small set of fields earns two-way sync: the basic contact identity that both teams genuinely keep current, like name, phone, and title. Even there I am cautious. My rule of thumb is start every field one-way and only promote it to two-way when someone can name the exact workflow on both sides that needs it. One-way fields are easy to debug. Two-way fields are where mysteries live.
Lifecycle stage deserves its own warning. It is the field most people set to two-way and most regret, because HubSpot workflows and Salesforce automation both want to move it, and they fight. Pick one owner. Usually HubSpot owns lifecycle up to the point of handoff, Salesforce owns everything after.
Where the sync actually breaks
Once the direction question is settled, the failures that remain are predictable. I have cleaned up the same four problems on nearly every account.
Duplicates from the email rule. HubSpot will not allow two contacts with the same email address. Salesforce will happily hold two leads with the same email, or a lead and a contact for the same person. When those try to sync into HubSpot, they collide on the one record HubSpot keeps, and that record gets overwritten back and forth. The fix is deduplication in Salesforce before you turn the sync on, plus a clear rule for lead-to-contact conversion. The native sync health report only flags duplicates that actively block a record, so plenty hide until you go looking.
Picklist mismatches. Salesforce opportunity stages, lead status, industry, any picklist. If HubSpot sends a value that does not exist in the Salesforce picklist, that record errors out and stops syncing. The most common version is an inactive opportunity stage: someone retires a stage in Salesforce, old deals still carry it, and they silently stop crossing. Keep the picklist values aligned on both sides and audit them when either team changes a dropdown.
API limits. This is the one that takes whole teams down. The integration runs on your Salesforce daily API call allocation, and a single contact sync can cost up to four calls. Push too many records and you blow the daily limit, at which point the entire sync halts until it resets the next day. Two things prevent it: an inclusion list so you only sync contacts that matter, and Selective Sync on the integration user so HubSpot never reads Salesforce records it does not need. Most "the sync just stopped" panics I get called into are an API ceiling, not a bug.
Custom objects and complex relationships. The native connector handles standard objects well. The moment you have custom objects, complex lookups, or a field with no clean equivalent on the other side, it gets thin. That is usually the signal you have outgrown the native connector, which I will come back to.
How I set it up, in order
Turning the connector on before the cleanup is how you replicate your mess into a second system at machine speed. I run it in phases instead.
The inclusion list is where I spend the most care, because it doubles as your handoff definition. I build a HubSpot active list of contacts at lifecycle stage MQL and above, or above a lead score threshold, and only those sync to Salesforce. That keeps Salesforce focused on sales-ready people and keeps your API budget alive. It also forces marketing and sales to agree on what "ready for sales" means, which is the same argument as your lead routing rules and worth having out loud.
Document the field map somewhere both teams can see it. When a number looks wrong six months from now, that document is the difference between a five-minute answer and a two-day investigation. This is the same discipline I push in any CRM integration architecture: decide ownership on purpose, write it down, sync one direction unless there is a real reason not to.
When to drop the native connector
The native sync is the right tool for a clean, mostly-standard setup under roughly 100,000 records. Past that, or once your data model gets custom, it starts to creak. Here is when I move teams off it.
You have custom objects with real relationships the connector cannot map. You need transformation in the middle, not just a one-to-one field copy, like reformatting values or merging two sources before writing. You need data from systems beyond the two CRMs in the same flow, like product usage or billing. Or you keep hitting API limits no amount of inclusion-list tuning fixes.
At that point I reach for a middleware layer. Sometimes that is a dedicated iPaaS, sometimes it is n8n running on your own infrastructure when you want control and GDPR-friendly data residency. The pattern is the same: one system of record per object, a middleware layer that logs every run and alerts on failure, and sync direction set on purpose. For pushing modeled data from a warehouse back into the CRMs, that is a reverse ETL job, not a job for the native connector. The native sync has no real logging and no alerting when a flow stops, which is fine at small scale and dangerous at large scale.
If you are not running both CRMs yet but are about to consolidate onto one, that is a different project with its own traps, and I covered it in the CRM migration playbook.
Two CRMs that disagree?
Book a free 30-minute audit and we will show you the three sync fixes we would make first, and whether the native connector is still the right call for your data.
Book an audit →FAQ
Can HubSpot and Salesforce sync in real time?
No. The native connector checks for changes about every fifteen minutes, so updates land within the quarter hour, not instantly. For anything that needs an immediate reaction, like routing a hot inbound the second it converts, build that path separately with a webhook or middleware rather than relying on the standard sync.
Should every field be a two-way sync?
No, and this is the most common setup mistake. Start every field one-way and only promote it to two-way when someone can name the exact workflow on both sides that needs both systems to write it. Marketing data should flow HubSpot to Salesforce, sales data should flow Salesforce to HubSpot, and only basic contact identity usually earns two-way.
Why do duplicate records keep appearing after I connect them?
HubSpot blocks two contacts with the same email, but Salesforce allows duplicate leads and contacts. When those collide on the single HubSpot record, it gets overwritten repeatedly. Deduplicate Salesforce before you turn on the sync, set a clear lead-to-contact conversion rule, and remember the sync health report only surfaces duplicates that actively block a record.
Why did my HubSpot Salesforce sync suddenly stop?
The most common cause is hitting your Salesforce daily API limit. The integration runs on that allocation, a single record sync can cost up to four calls, and once you exceed the daily ceiling the whole sync halts until it resets. Fix it with an inclusion list so fewer records sync and Selective Sync so the integration user reads less.
When should I replace the native connector with middleware?
Move off it when you have custom objects with complex relationships, need to transform data in transit, need other systems in the same flow, or keep hitting API limits. A middleware layer gives you logging and failure alerts the native sync does not, which matters once a broken flow can quietly corrupt thousands of records.
Get the sync right once
Most HubSpot to Salesforce problems are not bugs in the connector. They are a missing decision about who owns which field, made worse by a sync nobody monitors. Get the ownership map right, sync one direction unless there is a real reason not to, watch it weekly, and the two CRMs stop arguing.
If your two systems are telling two different stories, that is what we fix. See how we approach CRM and RevOps and AI and automation, or book a 30-minute audit and we will tell you whether your native connector is still the right tool or whether you have outgrown it.