A HubSpot field keeps changing back from Salesforce: sync rules, baselines and picklist errors

Start with the rule on the field

HubSpot's integration gives each mapped field one of four sync rules, and the rule decides which system wins. Prefer Salesforce unless blank lets HubSpot pass a value to Salesforce only when Salesforce has no value; otherwise the Salesforce value overwrites HubSpot. Always use Salesforce is one-directional: HubSpot never passes data, and Salesforce values always overwrite HubSpot. Two-way lets the most recent value overwrite the other. Do not sync means data never passes. Under the first two rules, a person who corrects the value in HubSpot will see it return, which looks like a fault but is the rule working as set.

Owner is the documented exception: it can be mapped only two-way, and the values must match exactly.

• Open the field mapping in the integration settings and read the rule.
• Ask which system people actually edit, and which should win.
• Check whether two mappings touch the same field.

The first sync and old values

Two documented details explain many surprises. Existing values do not sync retroactively when a new mapping is created. And for a contact with no sync history for that field, the first sync uses the current Salesforce value as the baseline, which can overwrite a newer HubSpot value. A mapping created after people have been editing in HubSpot can therefore replace their work the first time the record syncs. Test a new or changed mapping on a synthetic record before anyone relies on it.

Types, picklists and the errors they cause

A mapping can be saved only when the field types are compatible; for example a HubSpot dropdown can map to a Salesforce picklist and a single-line text property to a string. Even then, values have to line up. HubSpot's error article lists mismatched options, where the Salesforce option API names must match HubSpot's internal values; restricted picklist values, where it recommends turning off the restriction setting; inactive Salesforce owners; and state and country values that must be valid together. Each has its own documented fix. A value present in one system and absent from the other's list is rejected, so the record may stop syncing while others carry on.

• Compare the option lists on both sides by internal value, not by label.
• Check whether a restricted picklist is blocking the value.
• Check that an owner is active in Salesforce.

Where to see the errors, and who fixes what

HubSpot lists sync errors under Settings, Integrations, Connected Apps, Salesforce, Data sync, in the Sync Health tab, with a card for each error type and the option to export them. Some causes sit in Salesforce, such as custom code like flows and validation rules, duplicate rules and the integration user's field permissions; the article says these need your Salesforce administrator. After a cause is fixed, errors are resynced by hand, in batches of at most 100, so a large backlog needs another route. Do not resync a large batch before you know what the fix will do to live records.

What this guide does not cover

This guide does not connect the integration, add new objects or clean historical errors. It is not a substitute for your Salesforce administrator on flows and permissions. The paid outcome covers one mapped field pair: it reads the cause, corrects the mapping on the HubSpot side, names any Salesforce change for your administrator, and tests in each direction on a synthetic record. It does not bulk re-sync or edit live records.