When HubSpot and Salesforce disagree about who a customer is, your marketing team emails a lead your sales team already closed, and both teams stop trusting the sync.
Running HubSpot for marketing and Salesforce for sales is a common, sensible setup. Keeping the two systems agreeing about who a customer is turns out to be the hard part, and the cost of getting it wrong is not abstract: duplicate contacts, a rep working an account that already closed, a report two teams cannot agree on. The usual ending, if nobody fixes it, is somebody quietly turning the sync off and going back to CSV exports, which is worse than never syncing at all, because now the two systems have already drifted apart.
The native connector handles the common cases for free. A real fix for the rest starts from $4,999, scope-based, and most projects reach production inside a few weeks once the plan is agreed. Left alone, the cost does not stay flat. It grows every time someone merges duplicates by hand instead of fixing why they keep appearing.
TL;DR
- The native HubSpot Salesforce connector handles standard records well and costs nothing extra. Start there.
- It runs into trouble at four points: custom objects, identity matching, field-level conflicts, and knowing where a bad number came from.
- Stopping duplicates means picking a match rule before any record moves, not merging them after the fact.
- Stopping conflicts means writing down, in advance, which system owns which field.
- Custom integration work starts from $4,999, scope-based, with a 14-day money-back guarantee and a one-year bug warranty.
Table of contents
- Start with the native connector
- When custom work is actually worth it
- What this costs
- For your engineer
- FAQ
Start with the native connector
HubSpot ships a Salesforce connector, and it is competent. Per HubSpot's own installation guide, it maps standard records, syncs on a schedule, handles the field mappings you configure in the settings, and requires no engineering to turn on.
For a team running close-to-default setups on both sides, the native connector is often all you need. It handles contacts, companies, deals, and tickets without a developer in the room, and it does that job well. Try it first. Every hour spent building custom logic around a problem the connector already solves is an hour you will not get back.
The connector runs out of road in four predictable places: custom objects with real business meaning, contacts that show up as duplicates because of how identity gets matched, fields both systems think they own, and no way to trace a wrong number back to where it came from. Knowing these four in advance saves weeks of discovering them the hard way.
When custom work is actually worth it
You need custom work if two or more of these are true:
- Custom objects on either side carry real business meaning a generic mapping cannot capture.
- Duplicate contacts come back after every cleanup, because the root cause was never fixed.
- Both systems legitimately write to the same fields, and nobody has decided who wins.
- You need to trace any record back to the source that created it.
- Your record volume outgrows what a scheduled connector handles without falling behind.
If you answered yes to only one, the native connector plus some configuration discipline, and possibly one targeted marketplace app, may still be enough. Try that combination first. It is faster to set up, cheaper to run, and does not carry the maintenance cost that custom code brings with it.
What this costs
Two-way sync sits above the floor for HubSpot integration work, because the field ownership rules and the identity matching are genuine engineering, not settings you click through.
My work on this kind of integration starts from $4,999. The real number gets agreed in writing after a review of your specific fields and record volume, because scope drives cost here, not a flat rate. Every project ships with a 14-day money-back guarantee and a one-year bug warranty.
The calculator prices your specific scope in a few minutes, and the cost guide compares marketplace apps, other platforms, agencies, and custom builds side by side.
I hold several certifications from HubSpot Academy, including HubSpot Data Integrations Certified and Salesforce Integration Certification, alongside credentials covering platform consulting, reporting, and each major hub. For delivery proof, the Reevia case study is the clearest reference: four source systems merged into one HubSpot account, over 2 million records processed, source-to-HubSpot sync running in under 50 seconds, production reached in under four weeks.
For your engineer
The rest of this article is written for the person doing the technical work: your developer, your HubSpot admin, or whoever you bring in for the project.
Wall 1: custom objects. Standard objects sync well. Custom objects are where mapping gets thin. If your business runs on something that is not a contact, company, deal, or ticket, and you have modeled it as a custom object on either side, expect the connector to either ignore it or force it into a shape that loses meaning. HubSpot's own custom objects API guide confirms the object has to be created and schema-mapped through the API before any sync tool can touch it. Before committing to a custom build here, check the marketplace app limits guide.
Wall 2: identity matching. The connector matches contacts on email. That works until it does not: Salesforce holds a work email, HubSpot captured a personal one from a webinar signup; a lead is created before an email is known; one system lowercases emails, the other does not; a person changes jobs and the old email now points to a different company; two people share an inbox at a small company and both show up as one contact. Each of these produces a duplicate. Merging duplicates after the fact treats the symptom, because the next sync recreates them from the same root cause. Deciding what identity means, before any record moves: a primary key, usually an external ID from the source system rather than an email; a fallback of normalized email; a composite of email plus web address for shared inboxes; and an explicit tie-breaker rule, logged rather than silently auto-merged.
Wall 3: conflict resolution. Two-way sync is not one decision. It is one decision per field. When both systems can write to a field like lifecycle stage, something has to decide who wins when they disagree. Write the ownership table before anything gets built:
| Field | System of record | Rule |
|---|---|---|
| Lifecycle stage | HubSpot | Marketing owns it, Salesforce reads only |
| Account owner | Salesforce | Sales owns it, HubSpot reads only |
| Deal amount | Salesforce | Sourced from the opportunity, never written back |
| Either | Last write wins, every conflict logged | |
| Lead source | HubSpot | Set once at creation, never overwritten |
Two things fall out of this table for free: loop protection, so a change written by HubSpot does not bounce back from Salesforce as a fresh change, and auditability, so when someone asks why a field looks wrong, the table says who was allowed to write it and the log says who actually did.
Wall 4: observability. Eventually a number will look wrong, and you will need to explain it to someone who will not accept "the sync did it." A production integration lets you take any HubSpot record and trace it back to the source batch and the original payload that created it, answering which system wrote this value, when, and under what rule. This has to be built into how each write is logged from day one, because reconstructing that trail after the fact from two platforms' native logs is close to impossible once records have already synced dozens of times.
Practical design notes. Decide direction per object, not globally. Sync less than you think you need. Handle rate limits on both sides with batching, backoff, and idempotent writes, since HubSpot documents its current thresholds in its API usage guidelines and Salesforce enforces its own limits per org. Plan the backfill of existing records separately from the ongoing sync, against the same match rules, so historical duplicates actually get cleaned up rather than left in place.
FAQ
How long does a HubSpot Salesforce two-way sync take to build?
It depends on scope, not on the platforms themselves. A sync limited to standard objects with a clear ownership table can move fast. A build spanning several custom objects, a full identity-matching layer, and a backfill of existing records takes longer, because each piece has to be designed and tested on its own before they run together. The Reevia project, which merged four source systems into one HubSpot account, reached production in under four weeks.
What is the real difference between the native connector and a custom sync?
The native connector maps fields you configure and runs on a schedule; it does not decide who owns a field when both systems can write to it, and it does not resolve identity beyond matching on email. A custom sync adds the pieces the connector cannot decide on its own: a documented match key, a field-by-field ownership table, loop protection, and a way to trace any record back to its source.
How do you stop duplicate contacts between HubSpot and Salesforce?
You stop generating new duplicates by fixing the match key, not by merging the ones that already exist. A stable external ID from the source system, with normalized email as a fallback and a composite key for shared inboxes, closes most of the paths that create duplicates in the first place. Merging without fixing the match key resets the count until the next sync run, nothing more.
What does a custom HubSpot Salesforce integration cost?
Custom integration work in this space starts from $4,999, with the final number scope-based and agreed in writing after a review of your fields and record volume. The cost calculator gives a scope-specific estimate.
Can a marketplace app replace a custom two-way sync?
Sometimes, for a narrower slice of the problem. A marketplace app can extend object coverage or handle one specific gap without a full build, but most apps carry limits on volume or conflict handling that show up once you are running at real scale. The marketplace app limits guide covers where those limits typically sit.
Next steps
Start with the native connector if you have not already. It handles standard objects well, and there is no reason to build custom logic for a problem it already solves.
If you are hitting one of the four walls, custom objects, identity matching, conflict resolution, or traceability, write down your match key and your field ownership table before any work starts. Those two documents are what separate a sync people trust from one they quietly disable six months in.
When you are ready to scope the work, the cost calculator gives you a number based on your actual setup, and the service page has the full detail on how a project like this runs from review to production.