HubSpot and Salesforce picklist sync errors: why they happen and how to see them coming

A HubSpot to Salesforce picklist sync error almost always means one thing: a value exists on one side and not on the other. HubSpot sends a dropdown option that Salesforce does not have (or no longer has active), or Salesforce holds a value HubSpot has no matching option for, so the record does not sync. If the Salesforce field is a restricted picklist, Salesforce rejects any value outside its defined list. The fix is to make the two lists match again, then resync the records. The harder question is why they drifted apart in the first place, and that is nearly always a change made on one side without checking what else depended on the value.

The rest of this guide covers what each error means, what HubSpot and Salesforce document about them, the dependency chain the native tools do not show you, and a checklist for changing a picklist value without breaking the sync.

What HubSpot's sync error screen is telling you

HubSpot's Salesforce integration, its field mappings and its sync error screens are HubSpot's own. You find the errors under Settings, Integrations, Connected Apps, Salesforce, then the Data sync tab and its Sync Health tab, where each error type shows how many records it affects (HubSpot: Manage Salesforce integration API calls and sync errors).

HubSpot groups the picklist errors together and explains that records stop syncing because of a discrepancy between picklist values in the two systems. The ones you are most likely to see:

Error in HubSpot	What it means	HubSpot's documented fix
Error in HubSpotMissing Salesforce picklist option	What it meansHubSpot is sending a value that has no matching option in the Salesforce picklist.	HubSpot's documented fixMake the options match (see the next row).
Error in HubSpotMismatched options	What it meansThe option values differ between the two systems.	HubSpot's documented fixUpdate the API names of the Salesforce picklist options to match the internal values of the HubSpot property options.
Error in HubSpotRestricted picklist value	What it meansThe Salesforce field has "Restrict picklist to the values defined in the value set" turned on, and the value from HubSpot is not in that set.	HubSpot's documented fixHubSpot recommends turning that setting off in Salesforce so any value can sync. See the note below before you do.
Error in HubSpotOption limit exceeded	What it meansThe picklist has hit its maximum number of values.	HubSpot's documented fixDelete options neither team uses, in both HubSpot and Salesforce.
Error in HubSpotMissing or invalid opportunity stage	What it meansA Salesforce opportunity stage has no matching stage in the HubSpot deal pipeline.	HubSpot's documented fixAdd the stage to the corresponding HubSpot pipeline.
Error in HubSpotInactive opportunity stage	What it meansThe Salesforce opportunity is in an inactive stage.	HubSpot's documented fixMove the opportunity to an active stage in Salesforce.
Error in HubSpotTask Priority, Status or Type errors	What it meansHubSpot's task properties have fixed options, and the Salesforce values do not match them.	HubSpot's documented fixChange the Salesforce values to match HubSpot's options exactly, or remove the mapping.

All of these come from HubSpot's sync errors article. After you fix the cause, you go back to the error list, select the resolved errors and click Resync.

Notice the detail in the "Mismatched options" fix: matching happens on the internal value in HubSpot and the API name in Salesforce, not on the labels people see. HubSpot's property editor describes an option's internal name as the name used by APIs and integrations, generated from the label when the option is created (HubSpot: Understand the property editor). Two options can look identical on screen and still not match.

What Salesforce does with a value it does not recognize

A Salesforce picklist is either restricted or unrestricted, and the difference decides what happens to an unknown value coming in from another system.

Restricted. Selecting "Restrict picklist to the values defined in the value set" stops users loading unapproved values through the API (Salesforce Help: Create a Custom Picklist Field). Salesforce's SOAP API reference lists the error code INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST for an invalid or null value sent to a restricted picklist (Salesforce Developers: Core Data Types Used in API Calls). HubSpot's screen shows this as "Restricted picklist value".
Unrestricted. Users cannot type new values in the Salesforce interface, but the API, automation and other apps can still add them (Salesforce Help: Create a Custom Picklist Field; Trailhead: Guide to Creating Custom Picklists). So on an unrestricted field, a value that does not match may not raise an error at all; it can arrive as a new, unplanned value instead.
Global value sets are always restricted. If the field uses a global picklist value set, turning restriction off is not available, so the fix is to add the value to the set (Salesforce Help: Picklist Limitations).

A note on turning restriction off. HubSpot's recommendation works, but restriction exists for a reason: it keeps redundant or wrong values out of the field. Before you turn it off, decide whether you would rather have the sync fail loudly or accept whatever value arrives. Many teams keep the restriction and add the missing value instead.

Salesforce's own article for a different sync, its Account Engagement connector, lists the same Salesforce-side checks you will need for HubSpot: the value is spelled the same, it is active, it is allowed by the controlling field if the picklist is dependent, and it is enabled for the record type (Salesforce Help: Account Engagement Sync Error, Bad Value for Restricted Picklist Field). That article is written for Account Engagement, but the Salesforce field rules it describes are the same ones the HubSpot sync runs into.

The real root cause: a value changed on one side

The error screen tells you which record failed. It does not tell you what changed. In practice, picklist sync errors start with an ordinary edit made in one system:

Someone adds a new option to a HubSpot dropdown (a new industry, a new lead source) and nobody adds it in Salesforce. HubSpot's mapping page offers a manual Refresh that pulls new Salesforce picklist options into the HubSpot dropdown, but it works in that direction, and only when someone clicks it (HubSpot: Map HubSpot properties to Salesforce fields).
Someone deactivates or deletes a value in Salesforce while HubSpot records still hold it.
Someone adds a sales stage in Salesforce that the HubSpot pipeline does not have.
A picklist fills up and hits its value limit (Salesforce Help: Picklist Limitations).

Renames deserve their own warning. In Salesforce, renaming a picklist value changes only its label, not its API name, and Salesforce notes that report filters and automation referencing the old value may break or need manual updates. Replacing a value is a different operation: it rewrites every existing record that holds it (Salesforce Help: Difference between renaming a Picklist and replacing a Picklist value). Neither operation touches HubSpot.

What the native tools do not show you

Each system can show you part of the picture.

HubSpot shows where a property is used. The property editor's usage view shows where a property appears and its fill rate (Understand the property editor), and archiving a property lists the workflows and other assets that use it (Organize, delete, and export properties). From a workflow, you can review the lists and properties that workflow references (View workflow connections). These views work per property or per workflow. To find every workflow that branches on one specific option, you still open the workflows one by one.
Salesforce shows its own side: the value set, which values are active, the record types and the controlling fields.
The sync shows the records that already failed.

What none of them shows is the chain across systems for a single value. Take a synthetic example. Your Salesforce Account Industry picklist has the value SaaS - Enterprise. Across the stack, that one string may be:

The value a HubSpot workflow filters on to route enterprise leads, through the matching option on the contact industry property.
The value a reverse ETL sync (Fivetran Activations or Hightouch) writes into Salesforce or HubSpot from the warehouse.
A value a Salesforce report filter, flow or validation rule reads.

Rename it, retire it, or add a sibling value on only one side, and the failure shows up somewhere else: a sync error in HubSpot, a workflow branch that stops matching without any error, or a reverse ETL sync that starts pushing a value the restricted picklist rejects. The question that prevents the error is not "why did this record fail?" but "what depends on this exact value, in every system, before I change it?"

Checklist: changing a synced picklist value without breaking the sync

Before the change:

Find every use of the value, not just the field. In HubSpot, check the property's usage view, then open the workflows, lists and reports that use the property and look for the specific option. In Salesforce, check reports, list views and automation that filter on the value.
Check how the field is mapped. In HubSpot's Salesforce settings, open the object's property mappings and note the sync rule for this field (two-way, prefer Salesforce unless blank, always use Salesforce, or don't sync) (Map HubSpot properties to Salesforce fields). The rule tells you which side's change will be pushed to the other.
Check whether the Salesforce field is restricted, or uses a global value set. If it is, a value HubSpot sends must already exist in Salesforce.
Check record types and controlling fields. A value can exist on the field and still be unavailable for a record type or a controlling value.
Check other tools that write the field. Reverse ETL syncs, integration platforms and imports can send the value too.

Making the change:

Add before you use. Add the new value in Salesforce first, with an API name that matches the HubSpot option's internal value, then make it available in HubSpot. For Salesforce to HubSpot, use Refresh on the mapping to pull new Salesforce options into the HubSpot dropdown.
Retire with replace, not delete. To move records from an old value to a new one in Salesforce, add the new value, then use Replace. Deleting a value leaves existing records holding it (Difference between renaming and replacing), and those records can fail to sync later if the other side no longer has a matching option.
Watch the value limit. If you are near the limit, clean up unused options on both sides first.

After the change:

Update what reads the old value. HubSpot workflow branches and list filters, Salesforce report filters and automation.
Check Sync Health. Look for new picklist errors, fix the cause, then select the errors and click Resync.

How Meshie helps you see it coming

Meshie does not fix HubSpot sync errors, retry them or resolve them. HubSpot's Salesforce integration, its field mappings and its error screens are HubSpot's, and the fixes above happen there and in Salesforce Setup. Meshie reads configuration only, never records, and never writes to any connected system.

What Meshie adds is the dependency view for a single value, before you change it.

Every picklist value is its own node. That covers Salesforce custom picklists, standard value sets and global value sets, and HubSpot dropdown options on contact, company and deal properties. (HubSpot custom objects are not read yet.)
HubSpot workflow filters and branches resolve to the exact option they match, so you see which workflows depend on SaaS - Enterprise, not just on industry.
HubSpot options are linked to Salesforce values by matching option names on mapped objects (contacts to Lead and Contact, companies to Account, deals to Opportunity). HubSpot's native sync field mappings cannot be read through HubSpot's API, so Meshie does not read your mapping table, and it labels these links "matched by name" rather than "read from config".
Reverse ETL syncs inFivetran Activations (formerly Census) andHightouch that write HubSpot properties or Salesforce fields are read from sync config (Beta).
Every link shows its evidence and how it was found (read from config, observed, or matched by name), and every answer lists the systems it could not check.

When you are planning a picklist change, ask for it in the app, in Ask, or from any agent that speaks MCP. Meshie drafts the change, shows its blast radius across your connected systems, and gives a verdict: safe to hand off, needs review, or blocked. You make the change yourself, in Salesforce and HubSpot. After it ships, the next scan compares what changed with what was predicted. Free includes 10 change requests a month.

Between changes, scheduled scans compare each system's configuration with the last scan and notify you in Slack or by email when something changed. The app shows which Salesforce admin changed it, from the Setup Audit Trail. So a value someone added in one system can reach you as a change alert instead of first showing up as a sync error.

See it on a real answer. The sample report traces one Salesforce picklist value, SaaS - Enterprise, into a HubSpot workflow and two reverse ETL syncs, with the evidence and how each link was found and the systems it did not check. It runs on a synthetic demo org, not customer data.