§ CAPABILITY

Salesforce and HubSpot Integration

Product usage and revenue systems agreeing about the same customer. Identity resolved, ownership per field decided, and reconciliation that reports what it could not match.

Who
Delivered by a senior team assembled for the engagement, against a defined scope.
Request a call How the work runs

What you're seeing

Revenue and product data are reconciled by hand before a board meeting.
Usually means The systems disagree and a person is the reconciliation layer. The number reported to the board is currently produced by that person's judgement, which nobody has written down.
The same customer exists three times in the CRM.
Usually means Identity resolution was never decided, so each integration created records on its own terms. Deduplicating afterwards is materially harder than deciding the rule up front.
A field keeps flipping between two values.
Usually means Bidirectional sync where both systems believe they own the same field. Each system looks correct in isolation, which is why this class of bug takes weeks to diagnose.
Sales asks engineering what a customer is actually using.
Usually means Product usage never reaches the CRM, so the revenue team is operating on what customers tell them. It is the most common reason this work gets funded.

Identity first

Every later decision depends on how an account in the CRM maps to an organisation in the product.

It is almost never a shared key. It is a rule with exceptions: match on domain, except for the customers with three domains, except for the ones using a personal address, except for the enterprise account that is really four subsidiaries with one contract. Each exception is where a duplicate comes from.

Teams that skip this build a sync that works in testing — because test data is clean — and produces duplicates within a month of real traffic. The rule then has to be decided anyway, retrospectively, against data that is already wrong.

The workshop that settles it involves whoever owns the CRM, and their availability is usually the real scheduling constraint on this work.

Ownership per field, not per record

Record-level ownership is the intuitive version and it is where the arguments come from.

Billing owns the plan. The product owns last-seen and seats-in-use. The CRM owns the account owner and the renewal date. Marketing owns the lead source. Once that is written down as a matrix, bidirectional sync becomes safe, because no field has two writers.

Without it, both systems believe they own the same field, each writes what it believes, and the value oscillates. Diagnosing that takes weeks because every system inspected individually is behaving correctly.

Report, do not guess

A reconciliation job that silently resolves conflicts is destroying information, along with the evidence that it did.

The alternative is a scheduled report of what could not be matched and what disagreed — usually short, frequently empty — that a person looks at. That queue is not a sign of an unfinished integration. It is the mechanism that stops the slow drift back to two spreadsheets, and an integration honest about its own uncertainty is worth considerably more than one that appears to have none.

Where it sits

This capability sits under API Integration, which is the same discipline applied across systems of record generally, and under Software Development where the CRM connection is one surface of a larger product build.

It rests on two others. Backend & API supplies the interface and the retry and idempotency behaviour the sync depends on, and Database & Data Modeling is where the identity decision actually lands — the matching rule is a data model decision before it is an integration one.

How the work runs

  1. Resolve identity

    How an account in the CRM maps to an organisation in the product, and what happens when one buyer has three. This decision governs everything after it.

  2. Assign ownership per field

    Which system is authoritative for each attribute, and what happens when both change. Bidirectional sync without this produces a loop.

  3. Build the pipeline

    Idempotent handlers, retries with backoff, and a dead-letter path that a person actually monitors.

  4. Reconcile and report

    A scheduled job that reports unmatched and conflicting records rather than resolving them silently.

What arrives

  • An identity resolution rule agreed with revenue operations
  • A field ownership matrix covering both directions
  • Idempotent, retryable sync with a monitored dead-letter queue
  • A reconciliation report naming unmatched and conflicting records

What it costs your team

A workshop with whoever owns the CRM, then around two hours a week during build.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • Identity is resolved before anything is built

    Costs It requires a workshop with revenue operations before any engineering starts, and their availability is not usually on the project plan.

    How an account in the CRM maps to an organisation in the product governs every decision after it, including what a duplicate even is. Teams that skip it build a sync that passes testing and produces duplicates within a month, at which point the rule has to be decided anyway — retrospectively, against live data.

  • Field ownership is assigned per field, in both directions

    Costs It is a tedious matrix that has to be agreed by people from two different departments.

    Bidirectional sync where both systems own the same field produces update loops, and they are hard to diagnose precisely because each system is behaving correctly on its own terms. Ownership at record level is not enough — billing owns the plan, the product owns last-seen, the CRM owns the account owner, and that granularity is where the loops are prevented.

  • Conflicts are reported, never silently resolved

    Costs It creates a queue somebody has to look at, which reads as an unfinished integration.

    A reconciliation job that quietly picks a winner is destroying information, and it destroys the evidence of having done so. A visible gap is cheap to correct. A silent bad merge surfaces months later in a customer's invoice, with no record of what the other value was.

Frequently Asked Questions

Connecting a customer relationship system — Salesforce, HubSpot — to the product, so that both agree about the same customer over time. In practice it means deciding how an account in one maps to an organisation in the other, which system is authoritative for each field, and what happens when they disagree. Moving the records is the easy part.
Because they are treated as plumbing. Two systems that disagree about what an account is will keep disagreeing however reliably records move between them. Identity resolution and field ownership are the actual work; the connector is the straightforward part that follows from them.
Whichever your revenue team already runs. The product-side work is substantially the same either way, and we would not recommend a CRM migration in order to make an integration easier — that trades a bounded engineering problem for an unbounded organisational one.
Yes, with field-level ownership agreed first. Bidirectional sync where both systems own the same field produces update loops that are genuinely difficult to diagnose, because each system is doing exactly what it was told and looks correct when inspected alone.
Usually your own admin or a CRM partner, and that is the right split. We own the product side and write down the contract between the two systems — which fields cross, who owns each, what happens on conflict. That contract is the part that tends to belong to nobody.
With a matching rule agreed with whoever owns the data, applied as a report first rather than as a merge. The report is reviewed, the rule is adjusted, and only then does anything get merged. Merging first and reviewing after is not reversible in any practical sense.

Sources

Page reviewed