Two-Way Salesforce Contact Sync Reverts Lifecycle Stage
A B2B SaaS company has 64,000 HubSpot contacts and a two-way Salesforce contact sync. Three weeks ago the admin mapped Lifecycle Stage, Lead Status, and Contact Owner two-way. Since then 1,360 contacts have moved from MQL back to Lead, and marketing's MQL count dropped 18% week over week. The sync error queue shows 214 “invalid picklist value” errors for Lead Status and 76 “required field missing” errors for Owner. Marketing automation sets Lifecycle Stage in HubSpot from product-usage events; sales reps update Lead Status in Salesforce after calls. The company cannot change Salesforce picklist values this quarter, and marketing will not stop using Lifecycle Stage for segmentation. A spot check finds 82 contacts with duplicate email addresses, several created by the sync. The RevOps admin proposes turning off the sync for an hour during next Tuesday's campaign launch.
1. Which properties should be one-way, in which direction, and why? Specify the sync configuration changes you would make.
Read the worked answer
Treat each property as having one system of record rather than leaving the whole object in a broad two-way posture.
- Lifecycle Stage: HubSpot → Salesforce, one-way. Marketing automation owns the definition and the value set. Two-way mapping lets a Salesforce edit or a picklist mismatch overwrite the HubSpot value, which explains the MQL reversions.
- Lead Status: Salesforce → HubSpot, one-way. Sales owns this field and updates it after calls. HubSpot should consume it, not compete with it.
- Contact Owner: Salesforce → HubSpot, one-way, or stop syncing it. Owner assignment in HubSpot may be driven by workflows; two-way owner sync causes churn and the 76 required-field errors when Salesforce rejects a blank or inactive owner.
At the field level, change the direction of each mapping individually. Then fix the value mapping for Lead Status: map each HubSpot value to a valid Salesforce picklist value, and map any unmapped value to a neutral fallback rather than allowing an invalid write. Add a sync rule or exclusion list for records under manual review so remediation does not immediately re-trigger errors. Do not treat this as an object-wide on/off switch; the problem is field ownership and value mapping, not sync itself.
2. How would you remediate the 1,360 reverted contacts without causing a new sync storm during a campaign launch?
Read the worked answer
Fix the mappings first. If you restore Lifecycle Stage while both fields are still two-way, the next Salesforce update can revert the records again.
- Stop the bleeding: change Lifecycle Stage to one-way HubSpot → Salesforce and correct the Lead Status picklist mapping. Do not pause the entire sync for an hour during a campaign launch; that creates a backlog of queued changes and a larger conflict surface when sync resumes.
- Identify the affected population: pull the 1,360 contacts with current and prior values from property history or the audit trail. Separate true MQLs from records that should legitimately be Lead.
- Rebuild from the source of truth: re-run the product-usage criteria that should qualify an MQL rather than guessing from the reverted list. Set Lifecycle Stage in HubSpot through a controlled import or workflow after the mapping is one-way, so the corrected value propagates to Salesforce instead of being overwritten.
- Validate in batches: restore 50–100 records first, confirm the Salesforce value updates and no new sync errors appear, then restore the rest.
- Communicate: give sales a list of contacts whose stage changed and a short window to flag exceptions before the campaign sends.
3. What should be done about the 82 duplicate-email contacts, and what is the risk of ignoring them?
Read the worked answer
Deduplicate before doing more sync work. Duplicate emails make sync matching ambiguous: the integration may match a Salesforce contact to the wrong HubSpot record, create a new record, or return a duplicate-detection error. That can produce exactly the kind of inconsistent stage values already seen.
- Export the duplicate set and identify which record is the active sync-linked record. Merge into the record that has the sync history and the richer association set, not simply the newest record.
- After each merge, verify the surviving record still shows the correct Salesforce sync status. If the merge breaks the link, re-associate or re-sync deliberately rather than letting the next scheduled sync guess.
- Prevent recurrence: require email at creation where appropriate, run a dedupe automation on new contacts, and add a review queue for contacts created by the integration with an email that already exists.
Ignoring duplicates means the 214 picklist errors and the stage reversions will keep recurring even after the field mappings are fixed.