HubSpot Salesforce Integration: The Complete Guide to Two-Way Sync
The complete guide to HubSpot Salesforce integration: native connector vs real-time two-way sync, field mapping, conflict resolution, and sync-error fixes.
- Author
- Ruben Burdin · Founder & CEO
- Published
- May 6, 2025
- Read time
- 15 min read
Most companies that run both HubSpot and Salesforce didn't choose to. Marketing standardized on HubSpot for campaigns, forms, and lead scoring; sales runs the pipeline in Salesforce; and over time both systems ended up holding the same contacts, companies, and deals. The trouble starts the moment those shared records drift. A rep updates a phone number in Salesforce, marketing changes a lifecycle stage in HubSpot, and within a week the two systems disagree on who the customer is and where the deal stands.
A HubSpot Salesforce integration keeps the two CRMs aligned so a change in one shows up in the other instead of being re-keyed by hand. This guide covers why teams sync the pair, how one-way and two-way sync differ, what the native connector does and where it stops, every integration method compared in a table, object and field mapping, a step-by-step setup, the most common sync problems and their fixes, and how to keep the integration secure and inside API limits. If you are looking at the wider picture of CRM data integration, this is the connector-pair deep dive.
What Is HubSpot-Salesforce Integration?
HubSpot Salesforce integration is the process of connecting the two platforms so that customer data — contacts, companies, deals, and activity history — stays consistent across both. When it is configured well, a change made in either system is reflected in the other automatically, which removes manual export-import work and gives sales and marketing a shared view of every account.
Why teams run both HubSpot and Salesforce
- HubSpot is strongest at marketing automation, lead capture, email, and content, which is where most demand-generation teams live.
- Salesforce is the system of record for the sales pipeline, forecasting, and the deep customization that revenue and operations teams depend on.
- Companies migrating from one CRM to the other also need them connected during the transition so nothing is lost in the cutover.
Keeping the two in sync eliminates double data entry, prevents the conflicting records that erode trust in reporting, and lets marketing and sales act on the same facts. The hard part is not the initial connection — it is keeping thousands or millions of records accurate in both directions, every day, as schemas and processes change.
One-Way vs Two-Way (Bidirectional) Sync Explained
The first decision is direction. One-way sync copies records from a source system to a destination on a schedule or trigger; the source holds the single authoritative version and the destination is effectively read-only for the synced fields. That is fine when only one team edits the data — for example, pushing closed-won deals from Salesforce into HubSpot for reporting.
Two-way (bidirectional) sync treats both systems as peers. A change in HubSpot propagates to Salesforce and a change in Salesforce propagates to HubSpot, so each team can work in its preferred tool without overwriting the other. That flexibility is also what makes two-way sync harder: when both sides can edit the same field, the integration needs explicit rules for conflicts, loop prevention, and field-level change tracking. The two-way sync overview covers the underlying mechanics in depth.
The Native HubSpot-Salesforce Connector: How It Works and Where It Falls Short
HubSpot ships a native Salesforce connector, available on its Professional and Enterprise tiers, that handles the common case without a third-party tool. It maps HubSpot contacts to Salesforce leads or contacts, companies to accounts, and deals to opportunities, and it can sync activity history. Which records flow is governed by inclusion lists — a HubSpot list that defines exactly which contacts are eligible to sync.
What the native connector does well
- No extra subscription: it is included with qualifying HubSpot plans.
- Quick to stand up for standard objects with straightforward field mappings.
- Bidirectional for the core objects — contacts, companies, and deals — out of the box.
- Supported directly by HubSpot, with built-in sync health and error views.
Where the native connector falls short
- Periodic, not instant: the native sync runs on a periodic check (historically around every 10–15 minutes) rather than the moment a record changes, so sales can act on stale data.
- Inclusion-list friction: anything outside the configured inclusion list silently won't sync, a common source of "missing record" tickets.
- Field-mapping ceilings: complex transformations, conditional logic, and non-standard field types are limited or unsupported.
- Custom objects: native support for custom objects and their relationships is restricted, which breaks down for teams with tailored data models.
- One Salesforce connection per HubSpot account: consolidating multiple HubSpot portals into a single Salesforce org is not officially supported.
- Silent errors and API pressure: failed records can go unnoticed without proactive monitoring, and high-volume syncs can consume Salesforce or HubSpot API quota.
Integration Methods Compared: Native, iPaaS, Reverse ETL, Custom Code, and Real-Time Sync
Beyond the native connector, there are four broad ways to integrate HubSpot and Salesforce. They differ in how data flows, how fresh it is, and how much engineering they demand. The table compares them on the dimensions that decide which one fits.
| Method | How it works | Direction | Typical latency | Custom objects | Best for |
|---|---|---|---|---|---|
| Native connector | HubSpot's built-in Salesforce integration with inclusion lists | Two-way for core objects | Periodic (~10–15 min) | Limited | Standard contact/company/deal sync at lower volumes |
| iPaaS (Zapier, Workato, Boomi) | Pre-built recipes or flows triggered by events or schedules | Configurable per recipe, often one-way | Seconds to minutes | Varies by platform and tier | App-to-app automation and multi-step workflows |
| Reverse ETL | Pushes data from a warehouse back into the CRMs on a schedule | One-way (warehouse → CRM) | Scheduled to near real-time | Model-dependent | Activating warehouse and analytics data in the CRM |
| Custom code / APIs | In-house integration built on each platform's API | Whatever you build | Whatever you build | Full, if you build it | Highly unusual requirements with dedicated engineers |
| Real-time two-way sync (Stacksync) | Purpose-built bidirectional engine using CDC and webhooks | True two-way | Real-time (sub-second to seconds) | Full support | Operational CRM-to-CRM consistency at scale |
iPaaS tools are good at triggered automations ("when a deal closes, do X") but most run one-directional recipes rather than maintaining true bidirectional state with conflict handling. Reverse ETL is built for activating warehouse data, not for keeping two operational CRMs continuously consistent. Custom code can do anything in principle, but the two-way edge cases — conflicts, loops, schema drift, retries — become a permanent maintenance burden. For live operational consistency between HubSpot and Salesforce, a dedicated real-time two-way engine is usually the right tool.
Object and Field Mapping Between HubSpot and Salesforce
Because the two platforms use different data models, the integration has to map objects and fields between them. The standard object mapping is well established.
| Salesforce | HubSpot | Mapping notes |
|---|---|---|
| Lead / Contact | Contact | HubSpot contacts map to Salesforce leads or contacts; decide which, and how leads convert |
| Account | Company | One account to one company; watch for duplicate company domains |
| Opportunity | Deal | Map deal stages to opportunity stages explicitly — they rarely match by default |
| Task / Event / Activity | Activity / Engagement | Activity sync keeps a shared timeline across both systems |
| Custom object | Custom object | Limited natively; full field- and relationship-level mapping needs a dedicated platform |
Field mapping principles
- Match types, not just names: a text status in one system cannot land in a numeric or picklist field in the other without a transformation rule.
- Decide ownership per field: name which system is authoritative for each field before you turn sync on, not after a conflict appears.
- Handle required fields: a field that is mandatory on only one side needs a default value so writes don't fail.
- Map picklists and stages deliberately: deal stages, lead statuses, and lifecycle stages each need an explicit value-to-value map.
Step-by-Step: Setting Up a Real-Time Bidirectional Sync
A reliable HubSpot-Salesforce sync — native or third-party — follows the same rollout. The steps below assume a real-time bidirectional setup; the native connector follows the same shape with fewer mapping options.
- 01Plan objects and ownershipList the objects and fields to sync, and decide which system is the source of truth for each field before any configuration.
- 02Connect both platformsAuthenticate HubSpot and Salesforce with a dedicated integration user on each side, scoped to only the objects and fields you will sync.
- 03Map objects and fieldsMap contacts/leads, companies/accounts, and deals/opportunities, including stage and picklist value mappings and any custom objects.
- 04Set filters and scopeDefine which records are in scope — inclusion lists in the native connector, or filters in a sync platform — so you don't sync junk.
- 05Configure conflict rulesChoose how simultaneous edits resolve: last-write-wins, system priority, or field-level rules, set per field where it matters.
- 06Test in a sandboxRun both directions against test records, confirm relationships and required fields survive, and check the error log.
- 07Run an initial backfillLoad existing records in batches to stay within API limits, then verify counts match on both sides.
- 08Go live and monitorEnable real-time sync, watch latency, error rates, and conflict counts, and assign a clear owner for ongoing health.
Common HubSpot-Salesforce Sync Problems and How to Fix Them
Even a well-configured integration hits recurring issues. The five below account for most HubSpot-Salesforce sync tickets, and each has a concrete fix.
| Problem | Root cause | Fix |
|---|---|---|
| One-way / missing updates | Native connector treats some objects or fields as one-directional, or records fall outside the inclusion list | Enable two-way sync for core objects; widen inclusion rules; use a true bidirectional engine for full control |
| Duplicate records | No consistent unique identifier; records created separately in each system before sync | Standardize on email as the contact identifier; run deduplication; configure precedence rules |
| Sync errors / failures | Missing required fields, validation-rule failures, or permission gaps | Audit field mappings and required fields; check integration-user permissions; review error logs in both systems |
| API limit errors | High-volume syncs exceed Salesforce or HubSpot daily API quotas | Batch and throttle calls, sync incrementally, or use a platform with smart rate limiting |
| Field data mismatches | Incompatible field types between mapped fields | Audit types before mapping and add transformation rules; map picklists value-to-value |
The pattern behind most of these is the same: the native connector was built for standard, lower-volume sync, so complex bidirectional use cases expose its edges. Fix the simple issues first — duplicates and one-way settings — before reaching for API limits and custom objects.
Conflict Resolution and Field-Level Change Detection
A conflict occurs when the same field of the same record changes in both HubSpot and Salesforce before either has synced. Because both are valid sources of truth in a two-way setup, the integration must apply a deliberate rule rather than letting timing decide. The main strategies:
- Last-write-wins (timestamp): the most recent edit wins. Fine for high-volume, low-stakes fields; risky where an older value may be more accurate.
- System priority: a designated system always wins for given data — for example, Salesforce owns deal stage while HubSpot owns marketing fields.
- Field-level rules / merge: different fields resolve to different systems, so non-overlapping edits both survive and only same-field edits ever conflict.
- Manual review queue: ambiguous or critical conflicts are flagged for a human instead of being auto-resolved.
Field-level change detection is what makes this work in practice. If a rep updates a contact's title in Salesforce while marketing updates the same contact's lifecycle stage in HubSpot, field-level merging keeps both edits and never raises a conflict — a true conflict only happens when both sides touch the same field. The engine also has to track the origin of every change so its own writes don't echo back and create an infinite loop. Two stitched-together one-way pushes have neither capability, which is why they drift over time.
Handling Salesforce and HubSpot API Limits at Scale
Both Salesforce and HubSpot cap daily API calls, and a naive integration burns through them fast — especially during backfills or high-change periods. When the quota is exhausted, sync stops until the limit resets, which is exactly when teams notice stale data.
- Sync incrementally: move only the records that changed rather than re-scanning everything.
- Batch and throttle: bundle calls and pace them to traffic instead of firing one request per record.
- Schedule heavy loads off-peak: run large backfills when neither system is under user load.
- Use a platform with built-in rate-limit handling: a purpose-built engine batches, throttles, and retries automatically so you don't manage quotas by hand.
Security, Compliance, and Data Governance for CRM-to-CRM Sync
Syncing two CRMs moves customer data — names, emails, deal values, and sometimes regulated information — across a network boundary, so the integration is part of your security and compliance surface, not separate from it.
- Encryption in transit: data should move over TLS between systems.
- Dedicated integration users with least privilege: grant the sync only the object and field access it needs, and nothing more.
- Audit logging: keep a record of what changed, when, and which system initiated it, for compliance and debugging.
- Data minimization: sync only the fields the business needs, and filter out sensitive fields you don't.
- Vendor certifications: if you use a third-party platform, confirm it carries the certifications your industry requires, such as SOC 2, ISO 27001, HIPAA, and GDPR alignment.
The Business Case for Two-Way HubSpot-Salesforce Sync
The reason to invest in true two-way sync is operational, not technical. When HubSpot and Salesforce agree in real time, the work that used to happen between them — exporting, re-keying, reconciling — disappears, and the downstream effects compound across revenue operations.
- Faster lead handoff: a marketing-qualified lead in HubSpot reaches the right Salesforce rep immediately, instead of waiting for the next sync window.
- Cleaner reporting: when records match across systems, pipeline and attribution numbers can be trusted without a manual reconciliation step.
- Less engineering toil: a maintained sync removes the standing burden of fixing brittle scripts every time a schema or API changes.
- Better customer experience: support and sales see the same current context, so customers aren't asked the same question twice.
These benefits scale with data volume and process complexity — the more records and the more teams editing them, the more a reliable bidirectional sync is worth. The value comes from consistent, current data, so it depends on the sync actually being real-time and conflict-aware rather than a periodic batch that leaves windows of stale data.
Why Stacksync for Real-Time Bidirectional HubSpot-Salesforce Sync
Stacksync is a purpose-built platform for exactly this problem: keeping operational systems like HubSpot and Salesforce continuously consistent. Instead of periodic batches or two one-way pushes, it propagates changes bidirectionally in real time, wherever the change originated, so the two CRMs behave like one.
- True bidirectional sync with field-level change detection, so non-overlapping edits both survive and only same-field edits raise a conflict.
- Real-time propagation using change data capture and webhooks for sub-second updates, with scheduled options when you want them.
- Configurable conflict resolution per field — last-write-wins, system priority, or field-level rules — with resolutions logged for auditability.
- Reliability built in: automatic retries and replay so API rate limits and brief outages don't drop changes, plus an issue-management view to catch failures instead of discovering them later.
- Smart API rate limiting that batches and throttles calls so syncs stay within Salesforce and HubSpot quotas.
- Full support for standard and custom objects and fields, including data models the native connector can't handle.
- 1,000+ connectors across CRMs, ERPs, databases, and SaaS apps, configured through a no-code interface.
- Enterprise security and compliance: SOC 2, ISO 27001, and HIPAA, with encryption in transit.
- Usage-based, tiered pricing that scales with sync volume, starting around $1,000/month.
The result is enterprise-grade HubSpot-Salesforce sync stood up in days rather than months, without standing engineering maintenance. See how the two-way sync platform works end to end, and check coverage for your stack on the Salesforce and HubSpot connectors.
FAQ
Frequently asked questions


