A HubSpot–Salesforce integration that stops breaking: what we fixed at Viedoc

Why the two systems disagree

HubSpot and Salesforce both believe they own the customer. HubSpot has contacts, companies and lifecycle stages; Salesforce has leads, contacts, accounts and lead status. The standard connector maps them, but it does not decide who is right when they differ, and it matches mostly by email. Four things follow: duplicates on both sides, lifecycle stages that mean different things in each tool, sync errors nobody reads until the pipeline report is wrong, and custom objects the connector does not carry at all.

What we found at Viedoc

Viedoc is a clinical-trials data platform in Sweden with 52 Salesforce users. A large partner had launched Salesforce and left; the HubSpot integration was one of the things that did not survive the handover. Leads arrived with the wrong owner or not at all, the account lifecycle was tracked by hand, and the opportunity process depended on people remembering to update stages.

We took the org over as a Run engagement. The first week was a full review, not a fix. Then, in the first months: the HubSpot–Salesforce integration repaired, the account lifecycle automated so notifications went out on their own, and the opportunity process standardised. About forty tickets in four months, each one tested before go-live and logged. The client's Global Head of Sales Operations wrote afterwards that for a small team, a partner who tidies up as they go rather than adding to the pile is worth a great deal.

Five rules that keep it working

1. One system of record per field

Before any code, a table: field, system of record, direction, what happens on conflict. Lifecycle stage is owned by one side. Owner is owned by one side. The table is written down, agreed with marketing and sales, and it is yours.

2. De-duplicate before the first sync

A sync of duplicate data produces duplicate data faster. Matching rules beyond email, a merge pass with a record count you sign off, and only then the connector switched on.

3. Use the standard connector where it is enough, build where it is not

The HubSpot–Salesforce connector handles the common objects well when it is configured deliberately rather than left on defaults. Custom objects, custom properties and anything with rules go through Platform Events or REST, documented.

4. Make the errors visible

Sync errors go to a person, not to a log. A weekly five-minute review of the error queue, with a runbook that says what each error means and how to replay it, in your admin's hands.

5. Change it like production

A mapping change is a release: tested in a sandbox with a copy of the data, approved, logged, reversible. Most "the integration broke" calls start with "someone changed a property".

What it costs

One integration with a named result is a Two-Week Wins: two weeks, $5,500, $4,000 after the Health Check credit. Keeping it monitored is part of Run, from $1,600 a month. If the two systems have never been reconciled, the Health Check comes first: five days, read-only, and it tells you how bad the duplicates are before anyone promises a date.

What the field table looks like

Six rows, one meeting with marketing and sales, and most of the "the two systems disagree" calls stop. The table is the deliverable; the connector configuration follows from it.

Three signs your sync is already broken

1. The same company appears twice in Salesforce with different owners and one of them is marketing.
2. The HubSpot error log has more than fifty entries and nobody can say what the oldest one means.
3. Sales keeps a spreadsheet "for the real pipeline".

Any one of the three is enough to start with a Health Check rather than a fix, because the de-duplication count has to be agreed before anything syncs again.

The HubSpot and Salesforce page has the short version; the full Viedoc case has the rest of the story.