Why HubSpot-Salesforce Integrations Break, and What to Audit First

A HubSpot-Salesforce integration can run for years before anyone realizes the two systems no longer agree.

The first visible sign may be an opportunity that never reaches HubSpot, a contact property that keeps changing back or a report that no longer matches the number in Salesforce. By then, the integration may have accumulated years of new fields, changing permissions, revised qualification rules and one-off exceptions. Each change made sense on its own. Together, they have created an architecture nobody would intentionally design today.

The connector may still be doing exactly what it was configured to do. Its rules simply reflect an organization that has since changed.

Hypha’s position is that repairing a mature integration starts with understanding what each platform should own today. An audit should connect the symptoms to those ownership decisions, identify where the configuration falls short and establish who will keep it aligned as the business changes.

Why Correctly Built Integrations Deteriorate

An integration is configured around the business at a particular moment. The team decides which records should sync, maps the necessary fields, grants access and begins moving data.

The platform decisions behind it also reflect that moment. Our HubSpot Free CRM vs. Salesforce Free Suite comparison examines the starting limits and upgrade paths teams weigh when choosing a CRM. As the organization grows into more complex automation, reporting and handoffs, the integration needs to be reviewed against those new requirements.

The business keeps changing after launch.

Sales operations adds picklist values. Marketing revises its qualification criteria. Security reviews change service-account permissions. New integrations increase demand on Salesforce API capacity. Teams begin updating information in places the original implementation never anticipated.

Without a process for reviewing those changes together, the configuration gradually loses its connection to how employees work. Some changes block a sync. Others leave both systems operating with different versions of the same information.

The connector can enforce a rule. Deciding whether that rule still serves the business requires someone who understands the process behind it.

Where to Start: Match the Symptom to the Likely Cause

Start with a few affected records and a clear description of what should have happened. Record IDs, expected values and the timing of the discrepancy give an administrator something concrete to trace.

A reporting discrepancy alone does not prove the integration is broken. Two reports may use different populations or definitions. Establish that they are supposed to agree before changing the configuration.

1. Ownership Drift: Nobody Can Explain Which Value Should Win

A mapped field needs a business decision behind it: Which team maintains this information, in which platform, and under what circumstances should the other system change it?

Two-way sync deserves particular scrutiny when employees and automation can both update the same field. For established field pairings using that rule, HubSpot documents that the most recent value takes precedence. That makes the timing of an update consequential, even when the newer value is less useful to the business.

For example, an enrichment process might replace an industry value that a sales rep corrected after speaking with the customer. The integration has moved the data successfully, but the team has lost the judgment behind the correction. That is a data quality problem with consequences for segmentation, routing and reporting.

Use two-way mappings where the business has a reason to maintain the field in both systems. Where one team owns the value, review whether the mapping, editing permissions and automation support that responsibility.

Include Deletions in the Ownership Decision

Clearing a field is also an update. Under the Salesforce-preferred rules, clearing a Salesforce value clears its HubSpot counterpart; under Two-way, clearing either side can propagate to the other. HubSpot’s field-mapping documentation explains these behaviors.

A routine cleanup can therefore remove information that another team still uses. Before approving the repair, establish what a blank value means: Is the information unknown, deliberately withdrawn or waiting to be replaced?

Test that behavior alongside ordinary edits. Otherwise, the team may validate that new values arrive while missing what happens when someone removes them.

2. Configuration Drift: Settings No Longer Match the Systems

Permissions, field definitions and automation can change after implementation. Review the configuration against the current environment, using the affected records to narrow the investigation.

Check the Connected User Early

The Salesforce user connected to HubSpot determines what the integration can access and change. A permission change can interrupt a process that previously worked.

For missing opportunities, check the current deal-sync requirements, including Modify Metadata. HubSpot documents that permission in its integration requirements for deal syncing and HubSpot Embed.

Compare access with the intended design and coordinate any correction with the Salesforce administrator. The aim is to restore the required access with a clear explanation of why it is needed.

Look for Changes Shared by the Affected Records

If failures began after a new picklist value was introduced, check the mapping and refresh the Salesforce field where needed. Field types must also remain compatible.

Then look for the common pattern. Are the affected records from one business unit? Did they all pass through a revised workflow? Did the failures begin after a security review?

Those connections help distinguish a single bad record from a configuration issue affecting an entire population. Correct the cause, then test examples that previously failed and examples that were working before the change.

Internal documentation should be part of this review. If the runbook describes settings or components that no longer match the portal, update it alongside the repair so the next administrator inherits an accurate explanation.

3. Coverage Gaps: Records Were Never Eligible to Move

Some apparent failures begin with an assumption about which records the integration was supposed to include.

HubSpot’s inclusion segments determine sync eligibility. For contacts, initial creation and continued updates can behave differently: a Salesforce record may create a HubSpot contact even when that contact falls outside the inclusion segment, while subsequent updates remain blocked until it qualifies.

That distinction matters when someone says, “The contact is there, so why is the information old?” Its presence does not establish that it remains eligible for updates.

Review the business purpose behind the criteria. If marketing changed its qualification process, an older segment may exclude contacts sales now expects to receive. Also review Salesforce-to-HubSpot selective-sync controls separately for the relevant objects; one eligibility setting should not be assumed to govern every direction or object.

Confirm That Historical Records Were Included

Installing the integration does not automatically move all existing records. HubSpot documents imports and qualifying sync triggers as ways to bring them across.

Compare the original import scope with the population employees expect to see today. Older records may have been excluded intentionally, deferred until a later phase or missed entirely.

An audit should distinguish those cases before recommending a backfill. Moving every missing record could reintroduce data the organization deliberately kept out. Define the intended population, resolve duplicates and test a representative sample before expanding the repair.

4. Monitoring and Capacity Gaps: Maintenance Has No Accountable Owner

An integration needs someone responsible for reviewing exceptions and coordinating changes across platforms. Several teams may contribute, but one person should be accountable for making sure issues reach resolution.

HubSpot’s Sync Health settings show sync errors and the integration’s Salesforce API use over the previous 24 hours. Review that usage against its allocation and other demands on the Salesforce environment.

An error count is only the beginning of the assessment. Ten blocked records awaiting sales follow-up may deserve attention before hundreds of historical records with little operational impact. Give recurring issues an owner, a priority and a record of what changed.

The monitoring plan should also identify events that trigger a broader review: a new business unit, revised qualification rules, a security change or a major reporting requirement. These are opportunities to revisit the assumptions before employees discover the consequences.

What a Proper Integration Audit Should Produce

The central deliverable should be a system-of-record map: a written account of which platform owns shared records and important properties, who maintains them and how other systems use them. That gives the team a basis for reviewing the CRM data architecture and implementing repairs.

Here is an illustrative excerpt for an organization that runs marketing in HubSpot and sales in Salesforce. It describes business responsibilities; it is not a ready-to-apply mapping configuration or a client result.

The map should identify the actual objects and properties involved. “Salesforce owns sales data” is too broad to settle what happens when a workflow, rep or enrichment tool updates a specific field.

From there, the audit should produce:

• A prioritized repair plan explaining the affected processes, proposed changes and responsible people.
• Tested corrections to mappings, permissions and eligibility rules.
• A remediation plan for duplicates and historical records that should have synced.
• Documented results for record creation, updates, deletions and downstream workflows or reports.
• A named integration owner and a schedule for reviewing errors and proposed changes.

If the exercise reveals that the division of responsibilities itself no longer makes sense, use our guide to whether HubSpot can replace Salesforce to evaluate consolidation or continued coexistence. That decision depends on the processes Salesforce supports, where employees work and what leadership needs to report. Settling it gives the repair work a defined direction.

An audit is complete when the team can explain both the correction and the business rule it protects. That explanation is what helps the next process change avoid recreating the same problem.

Repair the Architecture Behind the Errors

An isolated failure may need a focused correction. Recurring discrepancies deserve a closer look at the rules connecting the two platforms and the processes that depend on them.

For an inherited integration, the most useful outcome is a clear account of what each system should own now, which changes will support that model and who will maintain it as the business evolves.

If your team has inherited an integration it did not configure—or the numbers in HubSpot and Salesforce have stopped agreeing—talk with Hypha about an integration architecture review. We can help trace the symptoms and develop a repair plan around the way your organization operates today.