HubSpot and Salesforce sync problems: causes and fixes

When your HubSpot pipeline report disagrees with your Salesforce dashboard, you need to establish which numbers can support a revenue decision.

A missing opportunity, an overwritten amount and a different reporting filter can produce similar symptoms. Each requires a different response.

This Huble guide examines six causes of HubSpot and Salesforce sync problems, with checks, corrective actions and validation steps for each. It is written for RevOps leads and CROs managing both platforms, particularly where acquisitions or multiple business units have increased complexity.

Huble provides CRM integration expertise for organisations connecting revenue systems. The starting point is a record-level diagnosis: establish what should sync, identify what happened, and determine whether the integration configuration supports your operating model.

Key takeaways: HubSpot and Salesforce sync problems

• Different pipeline totals can reflect reporting definitions rather than broken synchronisation, so reconcile the comparison before changing your integration configuration.
• Check field mappings, sync scope, duplicate records, Salesforce controls, API usage and opportunity associations as separate diagnostic categories.
• Define field ownership explicitly, because technically successful updates can still overwrite the values your revenue team intended to preserve.
• Validate corrected records and downstream processes with a controlled sample before expanding a resync to the wider affected population.
• Huble provides integration, migration and architecture services for organisations whose recurring sync problems require changes beyond individual field mappings.

Why do pipeline numbers differ between the systems?

Pipeline numbers differ when the underlying records, reporting definitions or synced values differ. Begin by determining which category explains your discrepancy.

Changing integration settings before establishing that distinction can introduce additional problems without resolving the original reporting question.

Choose a small set of opportunities from the disputed report. Compare their corresponding HubSpot deals individually, then document differences in inclusion, stage, amount, close date and associated records.

Compare the same opportunity population

Compare reports built from the same owners, business units, pipelines and opportunity types. An executive dashboard covering every Salesforce record type will not necessarily match a HubSpot report filtered to one pipeline.

Separate intended exclusions from failed syncs. If a pipeline is deliberately outside the integration scope, its missing deals are a design decision to explain, not an error to resync. Record the agreed reporting population before investigating individual failures.

Align reporting periods and revenue definitions

Use the same date basis in both reports. Created date, expected close date and the date an opportunity entered a stage answer different questions.

Review fiscal periods and timezones where records near a reporting boundary create discrepancies.

Compare weighted pipeline with weighted pipeline, and unweighted amounts with unweighted amounts. Also distinguish total contract value from recurring revenue. A successful field sync does not reconcile different commercial definitions automatically.

Check stages and currency before reconciling totals

Check whether stage values exist in the corresponding pipeline and remain active. HubSpot documents missing, invalid and inactive opportunity stages as sync-error causes. Matching labels alone do not establish that your reporting filters include equivalent stages.

For Salesforce opportunity currency values, the documented integration behaviour passes the numeric value without converting currencies or applying exchange rates.

Compare the currency context as well as the number. Equal amounts can represent different values, while different converted reporting totals can coexist with correctly synced source amounts.

Six causes of HubSpot and Salesforce sync problems

Sync problems can arise from configuration, record identity, Salesforce controls, capacity or relationship modelling. Investigate these separately, using the affected record and its error details rather than treating every mismatch as a connection failure.

Start in the Salesforce integration's Data sync area and review Sync Health. HubSpot's sync error documentation explains error categories, affected-record views, exports and resync options. Interface options depend on the object and sync experience enabled.

1. Field mappings and conflicting update rules

Field mappings determine which values correspond across the systems; sync rules determine how updates pass between them. A technically valid mapping can still create a commercial problem if its overwrite behaviour conflicts with your agreed field ownership.

How to spot mapping problems

Look for values that revert after an update, fields that never populate, or errors affecting a particular property. Compare the field types and allowed values on both sides. A Salesforce reference field and a HubSpot text property are not interchangeable simply because their labels describe the same concept.

Review the mapping itself and the record's update history. Check whether another workflow or Salesforce automation changed the value after a successful sync.

What to fix in field mappings

Correct incompatible field types and review each mapping's update rule. Standard rules include Prefer Salesforce unless blank, Always use Salesforce, Two-way and Don't sync. These have different overwrite and deletion behaviour; two-way is not a substitute for an ownership decision.

Document the authoritative source, permitted writers and expected blank-value behaviour for each important field. The updated deal sync has additional controls, so check object-level direction alongside field-level rules.

How to validate mapping changes

Test a populated value, an empty value and an update from each permitted source. Confirm that the expected value survives subsequent changes. Existing values in a newly created mapping do not retroactively sync automatically; plan a controlled resync where historical values need updating.

Keep the distinction between architecture and maintenance explicit. Huble's managed services include configuration documentation and change control, helping you maintain the decisions behind the mappings as your business evolves.

2. Inclusion segments and sync eligibility

Inclusion segments determine which HubSpot records are eligible to sync to Salesforce. Membership makes a record eligible; a sync trigger is still required. A record's existence in both systems does not establish that later updates should pass between them.

How to spot sync-scope problems

Investigate records that stopped updating after a segment change or never appeared in the destination. Check actual membership and the criteria behind it, rather than assuming a particular lifecycle stage guarantees eligibility.

Review the object and sync experience. Inclusion segments support contacts and other supported objects, including companies and deals after their respective sync upgrades. Do not assume every account has identical controls.

What to fix in inclusion criteria

Compare the configured segment against your agreed business scope. Correct accidental exclusions, but do not widen eligibility merely to remove a symptom. Acquired databases or separate regions may have legitimate restrictions that require review before sharing additional records.

HubSpot's inclusion segment guidance also distinguishes Salesforce-to-HubSpot selective sync. Check the appropriate direction and supported object rather than applying one filter model universally.

How to validate inclusion changes

Test both an eligible record and an intentionally excluded record. Confirm the expected creation and update behaviour separately. With configured Salesforce lead/contact creation, a HubSpot contact can be created even when outside the inclusion segment; later updates wait for eligibility.

First-sync exceptions also exist when HubSpot knows the Salesforce record identity before the corresponding HubSpot record exists. Treat inclusion criteria as sync controls, not as a complete security boundary for every first-sync scenario.

3. Duplicate records and incorrect matching

Duplicate Salesforce leads or contacts can repeatedly overwrite a HubSpot contact. Salesforce permits multiple leads or contacts with the same email address; HubSpot does not permit multiple contact records sharing that email.

How to spot duplicate-driven overwrites

Look for a contact alternating between values associated with different Salesforce records. Search Salesforce for matching email addresses across both leads and contacts, then identify the record currently linked to HubSpot.

For initial matching, Salesforce can return multiple matches in no particular order. HubSpot initially uses the first returned record and subsequently syncs with the most recently updated matching Salesforce record. Do not assume the oldest record necessarily remains authoritative.

What to fix before merging duplicates

Review the Salesforce records and choose the intended survivor. HubSpot's duplicate record guidance recommends retaining the currently syncing Salesforce lead or contact as the primary record during a merge.

Check deletion settings before merging: removing a secondary Salesforce record can affect the corresponding HubSpot contact where deletion propagation is configured. Preserve the relevant identifiers and associations, and obtain approval for destructive cleanup rather than treating it as routine resyncing.

How to validate record identity

Confirm that the surviving Salesforce record is paired with the intended HubSpot contact and that subsequent updates remain stable. If a different Salesforce primary was selected, the HubSpot contact may require a resync to establish the new pairing.

Do not extrapolate email matching to every object. Account, opportunity and custom-object matching have their own behaviour. In particular, configurable deduplication for updated deal sync is separate from contact matching.

4. Salesforce validation rules, automation and permissions

Salesforce can reject an otherwise valid integration request because of required values, validation rules, automation or missing permissions. Diagnose the rejection before changing the mapping: the connector may be sending exactly what it was configured to send.

How to spot Salesforce-side rejections

Read the error details and inspect affected records. Custom-code errors can originate from Salesforce automation, flows or validation rules. Permission errors identify access issues, while restricted picklists or missing required values require their own checks.

Compare a failing record with one that syncs successfully. Differences in record type, country, owner or required fields can help isolate the condition that causes the rejection.

What to fix in Salesforce controls

Work with your Salesforce administrator to correct invalid source data or make a narrowly justified rule adjustment. Preserve controls that protect data integrity. Do not broadly disable validation or exempt every integration update as a shortcut.

Check the integration user's access to the necessary objects and fields. HubSpot specifies Read and Edit access for Salesforce field-permission errors. Feature-specific prerequisites may require additional permissions; evaluate those separately rather than granting blanket administrator access.

How to validate permissions and automation

Resync a previously failing record after the correction. Confirm the intended values, associations and automation outcomes, not just the disappearance of an error. Then test another record that should still be rejected to ensure the control remains effective.

Export the relevant error set before remediation and compare affected records afterward. A lower error count supports progress, but only reconciliation establishes whether the business data is now correct.

5. API usage and delayed updates

API capacity can constrain integration activity, but delay alone does not prove API exhaustion. Review observed usage, configured allocation and sync errors before changing your integration's scope or assuming the connector is disconnected.

How to spot capacity-related delays

Check the API call use area in Sync Health. HubSpot displays usage over the last 24 hours, the limit determined by Salesforce and the allocation assigned to HubSpot. Compare these with activity from other applications using Salesforce.

Record when the delay began and whether a bulk import, large update or integration change preceded it. Correlation helps prioritise investigation; it does not establish a universal completion time for the delayed records.

What to fix in API allocation

Review HubSpot's allocation alongside the wider Salesforce workload. Raising one application's allocation does not create additional organisation-level capacity. Agree priorities with the owners of other integrations before changing the shared operating plan.

Schedule large updates deliberately and reduce unnecessary sync scope where business requirements permit. Avoid repeatedly resyncing the same unresolved error set. Correct the cause first, then plan the recovery workload.

How to validate capacity changes

Monitor usage and representative records through a normal operating cycle, including busy periods. Check that updates resume and that corrected records reach the destination with the intended values.

Do not promise a fixed sync interval or backlog-clearing time. The acceptance criterion should be an agreed business requirement supported by observed behaviour, not an assumed connector guarantee.

6. Opportunity associations and pipeline structure

Deal values can sync while their relationships remain incomplete. Missing company associations, contact roles or pipeline eligibility can undermine revenue reporting even when individual amount fields look correct.

How to spot relationship problems

Trace a disputed opportunity from its Salesforce account and contact relationships to the corresponding HubSpot company, contacts and deal. Check whether the record belongs to an eligible pipeline and whether its stage is valid.

Identify whether you use standard or updated deal sync. The updated experience supports configurable Salesforce record-type-to-HubSpot-pipeline mappings and association controls. Existing mappings migrate when enabled, so do not assume they must be recreated.

What to fix in opportunity sync

For standard opportunity sync, HubSpot documents company sync and a Salesforce account import as prerequisites for correct deal-company associations. Salesforce contact relationships use opportunity contact roles; a custom relationship field should not be assumed to have equivalent behaviour.

For updated deal sync, inspect pipeline mappings, association direction and labels in that experience. Review the updated deal sync documentation before changing architecture. Switching experiences is not a reversible troubleshooting test.

How to validate relationships and reporting

Use an eligible test opportunity with known account and contact relationships. Confirm the resulting deal's pipeline, stage and associations. Check report filters and lifecycle outcomes separately: the presence of an account association alone does not guarantee the expected contact lifecycle transition.

Use your agreed revenue definition to reconcile the test. Where structural differences exceed native configuration, assess additional integration logic instead of repeatedly repairing individual relationships.

How should you validate before a wider resync?

Validate a controlled sample and its downstream effects before resyncing the affected population. A successful test should demonstrate that the root cause is corrected and that the change preserves your intended business rules.

Build a representative test set

Select records covering the failure pattern, important record types and relevant exceptions. Include populated and blank values, permitted and excluded records, and the associations needed for reporting. Label this as your test sample, not proof that every record is fixed.

Capture the pre-change values and record pairings. Write expected results before triggering the test so the acceptance decision does not depend on whichever result appears afterward.

Check downstream automation and report reconciliation

Review workflows, routing, notifications and external reporting that consume the corrected fields. Determine whether changing a stage or lifecycle value meets their configured triggers. Coordinate any necessary controls with the process owners.

Compare the sample in both systems using the same reporting criteria. Expand remediation in controlled batches only after resolving unexpected results. Keep an exception log so residual discrepancies are investigated rather than hidden in an aggregate total.

When should you redesign rather than patch the integration?

Redesign becomes appropriate when recurring failures reflect incompatible ownership, processes or data structures rather than isolated configuration mistakes. Recurrence alone is a signal to investigate architecture; it does not automatically justify replacing a functioning native connector.

Resolve ownership and post-acquisition complexity

If teams repeatedly overwrite each other's data, agree decision rights before changing technical rules. Define the authoritative source for identity, opportunity progression, revenue amounts and lifecycle status. A connector cannot resolve organisational disagreement over those definitions.

After an acquisition, assess whether the integration still represents the combined operating model. Additional instances, overlapping records and local pipelines may require harmonisation. Huble's implementation and architecture services cover complex multi-region and multi-CRM environments.

Choose coexistence, custom integration or consolidation deliberately

Retain coexistence where each system has a defined role and native controls meet your requirements. Consider additional integration logic where necessary transformations or relationships cannot be represented reliably through those controls.

If the business intends to retire a CRM, assess Salesforce-to-HubSpot migration separately from immediate sync remediation.

A wider CRM comparison can inform the strategic choice, but does not replace diagnosis of today's reporting discrepancy.

How Huble supports integration troubleshooting and redesign

Huble provides CRM integration, migration and architecture services for organisations connecting HubSpot with other business systems. Its integration services include custom development and ongoing integration servicing.

Huble holds HubSpot's Custom Integration, Solutions Architecture Design and Data Migration. These capabilities support work that spans field configuration, data models and the wider operating environment, rather than treating integration reliability as a connection-status question alone.

The practical next step is to document the discrepancy, affected records, recent changes and required outcome. That evidence creates a useful starting point for determining whether targeted remediation or architecture work is appropriate.

For background on coexistence, the existing integration overview explains the rationale for running both platforms.

If your current setup needs specialist attention, speak with Huble about the integration and reporting problem you need to resolve.

FAQs about HubSpot and Salesforce sync problems

Why is a record missing after a Salesforce sync?

A record may be outside sync scope, awaiting a trigger or blocked by an error. Check the relevant object settings and affected-record details before recreating it. Huble's integration services support diagnosis where configuration and the intended architecture no longer align.

Why do synced field values keep changing?

Repeated overwrites can result from mapping rules, Salesforce duplicates or automation in either system. Trace the record pairing and field history before changing direction. Huble's architecture services help define ownership where teams require different systems to control the same value.

Why do reports disagree when the sync appears healthy?

Reports can disagree because of filters, dates, currency context, associations or revenue definitions even when values sync correctly. Compare individual corresponding opportunities first. Huble's managed services include analytics and reporting support alongside integration troubleshooting.

Which HubSpot partner can help fix Salesforce sync problems?

Huble provides integration services, ongoing technical management and CRM architecture support for organisations operating connected revenue systems. Its Custom Integration Accreditation supports that capability. Bring representative failing records and the required reporting outcome to make the initial investigation specific.

Does fixing the sync mean migrating away from Salesforce?

No. Targeted remediation can preserve a dual-system operating model where roles and data ownership are clear. Migration is a separate strategic choice. Evaluate it when consolidation supports your business objectives, rather than treating every sync error as evidence that coexistence must end.