Direction, ownership, matching, filtering and failure handling — five decisions per field, made deliberately or made by default. The default answers are what produce duplicate records, a cluttered CRM and two reports that disagree. We specify all five, field by field, and write them down.
Trusted by 500+ organizations — including B2B SaaS and technology companies running marketing in HubSpot and revenue in Salesforce with Twopir Consulting.
Sync Design & Data Governance
A broken sync announces itself. A badly configured one does not — it runs correctly, every fifteen minutes, quietly widening the gap between the two systems. By the time a report exposes it, months of divergence have accumulated.
The integration identifies duplicate leads and contacts by email address alone. Two addresses for the same human — work and personal, or a domain that changed — are two separate people as far as the sync is concerned, permanently.
The most common misconfiguration. When both systems can author a field, the last write wins, and the last write is frequently an automation nobody remembers building.
A required field, a validation rule or an unmatched picklist value rejects the update. Nothing surfaces it. One system moves on; the other keeps the old value indefinitely.
Salesforce matches on the internal API value, not the label. Two picklists that read the same in the interface can differ underneath, and every update against them is rejected.
Newsletter subscribers, event no-shows and job applicants arrive in the CRM alongside real buyers. Reps stop trusting the queue, and then stop working it.
Bulk imports, list re-scoring, mass property updates and large sends all draw on the Salesforce API allocation. Exhaust it and records queue rather than sync — and the integration can be suspended until calls free up.
The Salesforce HubSpot data sync is the field-level layer beneath the integration: for every mapped field, which direction data moves, which system is authoritative, how records are matched to one another, which records are allowed to cross at all, and what happens when a write is rejected. Those five answers, multiplied across every field, are the sync.
Direction is set per object and then refined per field — two-way, always use Salesforce, or always use HubSpot. The sync rule only applies where the object-level setting is two-way; a one-way object setting overrides it. Ownership follows from direction: engagement and scoring data is authored in HubSpot, pipeline and account data in Salesforce, and genuinely shared fields are the small exception rather than the default.
Matching is where most duplicate problems originate. HubSpot deduplicates Salesforce leads and contacts by email address, and that is the only field used. Records that represent the same person under different addresses will not be recognised. Resolving them means surfacing create date and the Salesforce Contact and Lead IDs, then merging in the correct system first so the sync links the surviving pair instead of recreating the duplicate. HubSpot documents this behaviour in its duplicate-handling guidance.
Filtering is the inclusion list — an active HubSpot list that controls which contacts may sync into Salesforce. Contacts not on it stay in HubSpot. One exception matters and catches people out: records created first in Salesforce can still sync to HubSpot regardless of the list. Failure handling is the decision nobody makes: what should happen when a write is rejected. The default is nothing, which is how divergence compounds unseen.
Twopir Consulting specifies all five for every field and hands over the document. We are a Salesforce Partner and a HubSpot Partner working with growing and mid-market companies — and enterprise organisations — on complex CRM, integration and business system challenges. For the wider integration this layer sits inside, see how the Salesforce HubSpot integration works, or start at our Salesforce and HubSpot integration services.
HubSpot offers three sync behaviours per field. Choosing correctly is not a preference — it follows from which system authors that piece of information.
| Sync rule | Behaviour | Use it for | Do not use it for |
|---|---|---|---|
| Two-way | Either system can update the field; the most recent write is kept. | Genuinely shared attributes with a single authoring team — a corrected phone number, a mailing preference. | Anything an automation writes on either side. Two automations plus two-way sync produces behaviour nobody can trace. |
| Always use Salesforce | Salesforce writes to HubSpot; HubSpot changes to that field are not sent back. | Account ownership, territory, opportunity stage and amount, closed-won status — anything finance or leadership treats as the record of truth. | Marketing engagement data, which Salesforce has no way to author correctly. |
| Always use HubSpot | HubSpot writes to Salesforce; Salesforce changes to that field are not sent back. | Engagement scores, email activity, original source, campaign membership, content interaction history. | Anything a rep is expected to correct in the CRM — their edit will be silently reverted on the next sync. |
| Do not sync | The field is deliberately left unmapped. | Internal scratch fields, system fields with no counterpart, and anything whose only purpose is to make one system's automation work. | Fields someone will later need in a report. Adding a mapping after the fact means backfilling history. |
Every deliverable here is a document as well as a configuration. Configuration without documentation is how the current situation happened.
The core artefact. Every mapped field with its authoritative system, sync direction, data type parity and conflict rule — written so it can be maintained after we leave.
Working with the connector's email-only matching rather than pretending it does more, and sequencing merges so cleanup does not generate a second wave of duplicates.
Deciding which records deserve to reach the CRM at all — the single highest-leverage change available on most cluttered Salesforce orgs.
Making failure visible. Where the native error surface is not enough, an Apex layer logs failures to a custom object and raises them to a human.
These are the checks that surface divergence before a report does. Run them quarterly, or after any change to fields, workflows or volume.
The sequence matters more than the speed. Every step exists because skipping it is how the environment we are called into got that way.
Record-level comparison across both systems to quantify divergence, plus a full read of the sync error queue grouped by cause rather than counted.
Field by field: authoritative system, direction, type parity, conflict rule and rationale. This document is the deliverable, and it outlives the engagement.
The configuration is built against a Salesforce sandbox with representative data, including the failure cases — a rejected validation rule, an unmatched picklist, an exhausted allocation.
Duplicate resolution ordered so merges resolve pairs instead of recreating them, with the inclusion list in place before volume moves.
Error alerting to a named owner, API allocation headroom alerts, the quarterly check schedule, and the documents in your hands.
A North America B2B SaaS company whose home-built sync had been failing quietly for months. The rebuild started with measuring exactly how far apart the two systems had drifted.
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.
A 47-field mapping specification with conflict rules per field, plus an Apex error-logging layer that made sync failures visible for the first time.
Any competent admin can make a sync work on a good day. The engineering is in what happens on a bad one.
The mapping document comes first. Configuring first and documenting later produces documentation that describes whatever was clicked, not what was decided.
Sandbox validation includes validation-rule failures, picklist mismatches and allocation exhaustion — the three things that actually take syncs down.
The connector matches on email only. Strategies that assume otherwise fail quietly, so we design around the real constraint rather than the desired one.
Merging in the wrong system first recreates the duplicates you just removed. Order is part of the deliverable.
Named alerting, a documented escalation path and a quarterly check schedule your team can run without us.
The native integration syncs on a near-continuous cycle rather than on a schedule you set, typically propagating changes within minutes. It is not a real-time transactional integration, and designing a process that assumes sub-second propagation — a rep expecting a field to update the instant a form is submitted — will produce complaints that look like sync failures but are not. Where genuinely low latency is required, that is a case for middleware rather than the native connector.
The inclusion list is a HubSpot active list that gates which contacts are permitted to sync from HubSpot into Salesforce — a record not on the list does not cross. Selective sync is the broader discipline of deciding, per object and per field, what should move at all. The inclusion list is the blunt instrument that keeps unqualified contacts out of the CRM; field-level rules are what keep the right records accurate once they are there.
Salesforce matches on the internal API value, not the display label, so two picklists that look identical in the interface can differ underneath — a trailing space, a different case, or a label that was renamed without the value changing. The update is rejected and lands in the error queue. Fixing it means aligning internal values on both sides explicitly rather than trusting the labels.
No — mapping them directly to each other is one of the most common causes of a funnel that means nothing. HubSpot lifecycle stage describes where a contact sits in the overall funnel; Salesforce lead status describes what is happening to that person right now. They measure different things. The workable pattern is a dedicated lifecycle picklist on the Salesforce side carrying the same values as HubSpot, with lead status left to sales as its own field. Note also that automatic lifecycle transitions will not move a stage backwards.
Records stop syncing and queue instead, resuming once calls become available. Sustained overuse can lead to the integration being suspended. The controllable part is setting the API call allocation in HubSpot deliberately against your Salesforce limit and monitoring headroom before large imports, list re-scores or mass property updates — those are the operations that consume allocation fastest.
Yes, on HubSpot Enterprise, with a limit on how many custom objects can be mapped. Direction follows the same logic as standard objects: whichever system authors that record type owns the field. Where the requirement exceeds what custom object sync supports — heavy transformation, high volume, or a third system in the path — middleware is usually the better answer than forcing it through the native connector.
Cleanup without prevention always regresses. Prevention means controlling record creation at the entry points — form handling, import process, and rep-created records — plus surfacing the Salesforce Contact and Lead IDs on HubSpot records so future merges resolve correctly. Merge order matters too: where both records carry Salesforce IDs, merging in Salesforce first lets the sync resolve the surviving record rather than recreating the pair.
Not usually. The native connector handles standard objects with per-field direction and conflict rules, which covers most requirements when it is configured deliberately. Operations Hub data sync adds value where you need custom field mapping beyond what the connector exposes, dedupe logic that does not fit email-only matching, or sync with systems beyond Salesforce. It is a real decision with a real cost, and it should follow from a requirement rather than precede one.
If Salesforce and HubSpot are telling different stories, the gap is measurable and the cause is findable. That is where we start.
Salesforce Partner · HubSpot Partner · Serving US, Canada, UK, UAE, Australia & New Zealand
