When a HubSpot company ends up paired with the wrong Salesforce Account, there is currently no self-service way to fix it. The Salesforce Object Id property is system-managed and read-only, the pairing is stored on HubSpot’s side, and Actions > Resync simply re-attaches the record to the same wrong account.
The only route today is a support ticket that gets escalated to the Product team for a manual backend reset, with no guaranteed timeline. Meanwhile, with the conflict rule set to “Prefer Salesforce”, the wrong account’s data continuously overwrites the HubSpot record, including unique identifiers used as dedup keys.
Support confirmed why this cannot self-correct: deduplication field mapping only determines the pairing at first sync. Once two records are paired, the integration links them by stored record IDs and never re-checks the dedup field, so a wrong pairing stays wrong until it is manually reset on HubSpot’s side.
Request: an admin-level action to re-pair a synced record. For example:
- A “Change synced Salesforce record” action on the Salesforce sync card, letting a Super Admin select the correct Salesforce record (with a confirmation step), or
- Making the Salesforce Object Id editable or clearable for Super Admins, so the record can re-pair through the existing resync flow.
Why this matters:
- Mis-pairings are inevitable at scale (mismatched dedup values at first sync, duplicates, merges). Each one currently costs a support ticket plus Product team involvement for what is conceptually “point record X at record Y”.
- While waiting for the manual reset, data quality on the affected record actively degrades.
- Admins already control sync rules, field mappings and dedup settings. Re-pairing a single record is a natural extension of those permissions.
This hit us on company records, but the same capability would be valuable for contacts and deals.