HubSpot Salesforce integration.
Two systems of record, one truth. The HubSpot Salesforce connector is easy to switch on and hard to live with. Everything depends on decisions it asks you to make in a dialog box: which system owns each field, what syncs, and what happens when both sides change the same record.
Both systems think they own the field.
Marketing updates a lifecycle stage in HubSpot. An admin updates the same underlying field in Salesforce. The connector resolves it according to a rule somebody set in the first week and nobody has looked at since, and the number in the board deck slowly stops matching the number in the CRM.
Last write wins. Nobody chose that.
Salesforce — the sync conflictThe decisions the connector makes you make.
Field ownership, written down
Every synced field gets a declared owner and a direction. Two-way sync on a field neither system truly owns is the root cause of most data disputes we are called in to settle.
Selective sync, deliberately
Syncing everything costs API calls and marketing contact allocation and imports Salesforce records nobody markets to. An inclusion list based on what marketing actually acts on is cheaper and cleaner.
Lead and contact reconciliation
Salesforce leads and contacts both become HubSpot contacts. Conversion behaviour, and what happens to the HubSpot record when a lead converts, has to be defined rather than discovered.
Campaign and attribution flow
HubSpot campaign membership and Salesforce campaigns can stay in step, but only with a mapping that survives someone renaming a campaign. Attribution reporting lives or dies on this.
API limits and sync timing
A bulk update in either system can exhaust a daily API allocation and stall the sync silently. We build with batching in mind and alert on a stalled queue rather than finding out at month end.
Reconciliation on a schedule
Counts compared on both sides weekly, with a report that names the drift. A green connector status is not evidence that the data agrees.
Built to a contract, not to a connector.
Draw the boundary
Which system owns which field, in writing, before a line of code. Most broken integrations are two systems both believing they are the source of truth.
Model the join
The key that matches a record on one side to a record on the other, and the rule for what happens when it does not match — because it will not match.
Build and instrument
Sync built with retries, idempotency and a dead letter path, plus logging you can read without opening a console.
Reconcile
Counts compared on both sides on a schedule, with a report that names the drift rather than a green tick that hides it.
Hand over
A runbook covering the three failures that actually happen, so the next person does not have to reverse-engineer the design from the logs.
It was set up in an afternoon.
The connector installs in minutes, which is exactly why it is so often the least considered system in the estate. Two years later nobody knows why a field stopped updating, the sync error queue has four thousand entries, and the honest fix is to redesign the boundary rather than debug the symptom.
What people ask before they commit.
Should we use the native connector or build something custom?
Native, in almost every case. It is well built and it covers the standard objects properly. Custom code is for the gaps — a custom object relationship the connector does not model, or a transformation it cannot express.
Can we sync only some records?
Yes, with an inclusion list, and you usually should. It controls cost, keeps the marketing contact count honest, and stops Salesforce records that will never be marketed to from filling the portal.
What happens when both systems change the same field?
Whatever the sync rule says, which is why the rule matters more than the connector. We set a preferred system per field rather than leaving it on the default and hoping.
Will this fix our reporting disagreement?
Only partly. Most reporting disputes are definition problems, not sync problems — two teams counting an opportunity differently. We fix the definitions first, because a perfect sync between two different definitions still produces two numbers.
How long does it take to set up properly?
Two to five weeks for a considered implementation including field mapping, testing and reconciliation. Switching it on takes an afternoon, which is the trap.
Where people go from here.
Draw the boundary once.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.