HubSpot and Salesforce, without the sync war.
Two systems that both consider themselves the CRM, syncing the same fields in both directions. The technical setup is straightforward; the governance is where this succeeds or fails.
Why the stock connector isn’t the end of it.
This pairing usually arrives by accident. Marketing adopts HubSpot, sales already runs Salesforce, and the native sync is switched on to bridge them. It works until the two systems disagree about a field, at which point whichever wrote last wins — and nobody can explain why a lifecycle stage reverted overnight.
The native integration is capable software. What it cannot do is decide your data governance for you, and that is what most of these projects actually need: a clear statement of which system is authoritative for each object, and what happens on conflict.
Where it breaks.
Each of these is something we have had to unpick on live systems.
Bidirectional sync has no correct conflict resolution
When both systems can write the same field, the outcome depends on timing you do not control. Last-write-wins is a coin toss dressed as a rule. Fields that genuinely need to move should be one-directional with a named owner; only a small number ever truly need both directions.
Lifecycle stage and opportunity stage are different things
HubSpot lifecycle stages describe marketing progression; Salesforce opportunity stages describe a sales process. Mapping them one-to-one produces contacts that regress to 'Lead' after sales has advanced them, which erodes trust in both systems within a quarter.
Picklists drift apart
Someone adds a value in Salesforce and not in HubSpot. Records with that value fail to sync, usually silently, and the error log is not something anyone reads daily. Six weeks later a segment is missing records and nobody knows for how long.
Duplicates multiply across the boundary
HubSpot deduplicates on email; Salesforce does not deduplicate Leads and Contacts by default. The same person can exist as a HubSpot contact, a Salesforce Lead and a Salesforce Contact simultaneously, and syncing does not resolve it — it propagates it.
Sync loops burn API calls
A write in one system triggers a write in the other, which can trigger an update back. With workflows firing on record change this can run in circles, consuming Salesforce API allocation and producing an audit trail nobody can read. It rarely announces itself until you hit a limit.
How we approach it.
We map objects and fields to a single owner before touching configuration. Contacts and marketing engagement generally belong to HubSpot; accounts, opportunities and anything a rep is measured on belong to Salesforce. The point is not that specific split — it is that the split exists and is written down.
Conflict-prone fields get one direction only. Where a business genuinely needs bidirectional behaviour, we implement it explicitly with a defined precedence rule rather than relying on last-write-wins, and we make the rule visible to the people whose data it governs.
Deduplication is handled before the sync is enabled, not after. Turning on sync across two dirty databases does not merge them; it multiplies the mess and makes it considerably harder to unpick.
Questions people actually ask.
Sometimes the honest answer is no, and consolidating onto one is cheaper than integrating two. It is worth asking before investing in the sync. Where both genuinely earn their place — HubSpot for marketing automation, Salesforce for a complex sales process — the pairing works, provided ownership is clear.
For standard objects and a clean field map, yes — it is well-built and we often use it as the transport. What it does not solve is governance: which system wins, how conflicts resolve, and how deduplication works. Those decisions sit outside any connector.
Most often a picklist value exists on one side and not the other, or a required field is empty, or a validation rule rejects the write. These surface in a sync error log rather than as a visible failure, so they accumulate quietly. We route sync failures somewhere a human actually looks.
As a discrete cleanup project before enabling sync. That means agreeing matching rules, reviewing merges where the rules are ambiguous, and accepting that some judgement calls need a human. It is unglamorous work and it is far cheaper than doing it afterwards across two systems.