Why your HubSpot and Salesforce records do not match

The short version of what goes wrong

A sync gets switched on, it works for a fortnight, and then someone notices a lifecycle stage in one system that disagrees with the other. Nobody changed anything. Both systems are behaving exactly as configured.

That is the part worth sitting with. In almost every case we are called into, nothing is broken. The integration is doing precisely what it was told to do, and what it was told to do was never written down.

---

Reason one: both systems can write the same field

Bidirectional sync is the most requested feature in any CRM integration and the one that causes the most damage.

Two systems that can both write the same field will eventually disagree, because they are being updated by different people for different reasons at different times. When they disagree, one overwrites the other on whatever schedule the integration runs. Nobody remembers configuring that schedule, and the overwrite leaves no visible trace.

The result is a field that changes value on its own. A sales rep sets a stage on Monday, marketing automation sets it back on Tuesday, and by Friday nobody trusts the field enough to report on it.

The alternative is unglamorous and it holds. For every synced field, one system owns it and the other is read only:

• Lifecycle stage is owned by marketing automation.
• Deal stage is owned by the CRM.
• Billing status is owned by the billing system, and nothing else may write it.

Where a field genuinely has to be writable in two places, it gets an explicit conflict rule and a timestamp comparison rather than a hope.

---

Reason two: the two systems disagree about what a duplicate is

Every CRM has a merge function. None of them can tell you what should have been merged, because that is a judgement rather than a calculation, and the two systems are usually making different judgements.

The match key decides everything. Matching on exact email address is safe and misses most duplicates, because the same person appears as a work address, a personal address, and a typo. Matching on email domain is aggressive and will merge two unrelated people at a large company. Matching on normalised company name catches Acme Ltd, Acme Limited and ACME, and also merges genuinely separate entities that happen to share a name.

If system A matches on email and system B matches on domain, they will build different pictures of the same customer, and no amount of syncing will reconcile them. The records are not out of sync. They are answers to different questions.

---

Reason three: survivorship was never decided

When two records merge and their values disagree, something has to win. Most teams never make that choice explicitly, so they inherit the platform default, which is usually newest wins.

Newest wins is frequently wrong. The newest value often came from a web form where someone typed their name in lowercase and their company as "acme". The older value came from a signed contract.

Source-based survivorship works better. Values from the billing system beat values from a form, which beat values from an enrichment tool. It takes an afternoon to agree and it stops the slow degradation of every record that passes through a merge.

---

Reason four: the sync is failing and not telling you

Integration errors are usually visible only inside the integration, on a screen nobody has open. A required field rejects a value, a rate limit is hit during a bulk update, an API token expires. The sync carries on with the records it can process and quietly skips the ones it cannot.

Weeks later the symptom appears as a gap that makes no sense: a set of contacts created in one system that never arrived in the other, with nothing in common except the date.

Any integration handling records you report on needs failure alerting that reaches a human, not a log that someone might check.

---

The document that prevents all four

The deliverable that fixes this is a field mapping table. Every synced field, its direction, its owning system, and its conflict rule. Four columns.

It is boring to produce and it is the document your team will actually open in eighteen months when something looks wrong. It also makes the next integration cheaper, because the decisions have already been made and written down.

If your marketing and sales numbers have never quite reconciled, this is usually where it started, and it is usually a shorter piece of work to fix than people expect once the object model is agreed.