Diagnosing a Salesforce-HubSpot sync conflict that grew past 3 million error records
An enterprise HCM and payroll SaaS provider's continuous Salesforce-HubSpot sync carried 26,839 error records at a first audit, past 3 million by a second audit a year later, concentrated in task and meeting fields whose Salesforce picklist values HubSpot's own properties couldn't be edited to match. The same review found a third system writing to the same contact fields.
Executive Summary
Context
The client is an enterprise HCM and payroll SaaS provider whose Salesforce-HubSpot sync compounded a platform mismatch from 26,839 error records to an estimated 3 million or more, then turned up a nightly sync from an internal HR database overwriting the same contact fields.
What We Built
An audit quantified a growing sync-error count, traced it to a mismatch between the two platforms' data models, and disabled the fields responsible while the picklist fix waits on Salesforce. The same audit surfaced a second, unmapped sync writing to the same contact fields.
Tech Stack
- Salesforce (native HubSpot connector API
- Task, Meeting, and Ticket objects), HubSpot CRM (Sales Hub, Service Hub), Dell Boomi (integration middleware), the client's internal HR database.
Not a fit if your Salesforce and HubSpot instances share matching picklists and one system feeds contact data. This exists because a continuous sync compounded an unaddressed mismatch into a seven-figure error count, and a second, unmapped system was found writing to the same fields.
The Challenge
The client's Salesforce and HubSpot instances run a continuous, two-way sync. HubSpot's own Task and Meeting properties can't be customized to match Salesforce's exact picklist values. Those properties include hs_task_priority, hs_task_type, hs_task_status and meeting location type. HubSpot also allows many-to-many associations where Salesforce enforces a strict one-to-one model. Neither limit is a configuration mistake. Both are how each platform is built.
A first audit counted 26,839 sync-error records. A follow-up roughly a year later found the estimate had grown past 3 million, with 1.66 million task-priority, 1.45 million task-type and 98,000 meeting-location errors. One affected property tracks meeting type, the same field behind the client's own marketing north-star metric.
The same review turned up a conflict nobody had been watching for. A nightly sync from the client's internal HR database, through Dell Boomi into Salesforce, was overwriting the same contact fields.
Our Approach
We didn't wait for a cross-team picklist fix while the count kept compounding. We disabled the mismatched fields responsible for nearly all the errors, and reprioritized the audit around Task and Meeting fields, putting a smaller Ticket-field mismatch behind them. The sync stayed on, and only the fields producing bad data were pulled out.
The same review traced the nightly Dell Boomi job that feeds the HR database into Salesforce and overwrites work-contact fields with personal-contact data. Desyncing the phone-number field on HubSpot's side was on the table, but the connector requires two-way sync, so we ruled it out. We flagged the conflict for a Salesforce-side fix instead, since it's a question of two-way sync governance, not a one-sided change.
The trade-off is that the disabled fields stay out of the sync until Salesforce's picklist values are reworked to match HubSpot's. The contact-field conflict stays open until the Salesforce-side rule is written.
Impact
A silent, compounding error count became a measured one
A single point-in-time count meant little on its own. The follow-up audit showed how fast the mismatch compounds, past 3 million within about a year, broken down by field rather than left as one total, which is what let the team decide where to act first.
The fields doing the most damage were stopped, not left running
Rather than wait on a Salesforce-side picklist fix with no committed date, we disabled the fields responsible for nearly all of the counted errors. The sync itself kept running; a lower-volume Ticket-field mismatch found in the same audit was deprioritized behind it.
A third system writing to the same fields came to light
The same review traced a nightly sync from the internal HR database, through Dell Boomi into Salesforce, overwriting the same contact fields the HubSpot sync depended on. Two platforms disputing a field was already hard to diagnose; a third made clear the fix belonged at the data-model level.
The fix was routed to where it could actually be resolved
A proposal to simply desync the phone-number field on HubSpot's side was rejected once the connector was confirmed to require two-way sync or none at all. The conflict was flagged instead for a Salesforce-side rule, the only place able to decide which value wins.
HubSpot's Task properties, hs_task_priority, hs_task_type, and hs_task_status, plus its meeting-location-type property, ship with fixed values that can't be edited to match Salesforce's picklists. Every sync cycle that meets a Salesforce value with no matching HubSpot option writes an error record instead.
HubSpot allows a record to carry many-to-many associations where Salesforce enforces a strict one-to-one model. The native connector, built to satisfy both platforms at once, errors whenever a HubSpot-side association has no single Salesforce equivalent.
The fields responsible for nearly all counted errors were disabled from the active sync individually, while the sync itself, and every other field it carries, kept running. The disabled fields wait for reinstatement once Salesforce's picklist values are reworked to match HubSpot's.
A nightly Dell Boomi job pulls from the internal HR database into Salesforce, writing to the same contact fields the Salesforce-HubSpot sync carries. The connector requires bidirectional sync, so the conflict depends on a conditional rule written into Salesforce itself, not on disconnecting one side.
Salesforce and HubSpot sync Task, Meeting and Ticket records continuously through the native connector. When a Salesforce picklist value has no match in HubSpot's fixed property options, the connector writes an error record instead of updating, so the mismatched fields were disabled from the sync while the Salesforce-side fix waits. Separately, a nightly Dell Boomi job loads personal-contact data from an internal HR database into Salesforce, and it overwrites the same contact fields the connector carries to HubSpot. That conflict stays open, because the connector requires two-way sync and the rule has to be written in Salesforce.
FAQ
The picklist values that need to change live on the Salesforce side, outside this audit's own scope and on a separate team's schedule. Disabling the specific mismatched fields stopped the error count from compounding immediately, without waiting on a cross-team change with no committed timeline.
A nightly Dell Boomi job had been syncing the internal HR database into Salesforce, independent of the Task and Meeting sync-error audit. It surfaced only because that review traced which system had most recently written to the disputed fields, rather than assuming Salesforce and HubSpot were the only two in contention.
