Default Country Workflow Overwrites Synced Canadian Contacts
A company has a two-way contact sync with Salesforce. Salesforce is the source of truth for billing country. A workflow called “Default country” runs when a contact is created and sets Country to US if the field is blank. Contacts created by the Salesforce sync initially arrive with a blank country, the sync fills the country a moment later, but the workflow fires in between and writes US. On the next sync, the HubSpot value is newer, so US propagates back to Salesforce. About 2,300 Canadian contacts are now marked US, including 600 in Quebec. Marketing uses country for segmentation and email compliance footers. The team also has a data quality automation that formats country values to two-letter codes. The admin cannot pause the global sync during a product launch.
1. Explain the race condition and why the sync did not correct the country value.
Read the worked answer
Three writes are competing: the sync creates the contact with a blank country, the creation workflow writes US, and the sync then writes the actual Canadian country. The workflow fires on creation, before the sync's country value has settled. Its US write becomes the most recent change. When the next sync cycle compares the records, HubSpot's US value looks newer than the original Salesforce value, so the two-way mapping sends US back to Salesforce.
The formatting automation can compound the problem: if it changes “CA” or “Canada” to a different value, that is another write that can trigger sync reconciliation. The root cause is not bad Canadian data; it is an automation writing a default into a property whose system of record is Salesforce. A default value is only safe when the application owns the field and can distinguish “unknown” from “not yet synced.” Here it could not.
Changing the mapping to Salesforce → HubSpot one-way for Country removes the path for HubSpot to overwrite the source of truth.
2. How would you remediate the 2,300 affected contacts and prevent recurrence?
Read the worked answer
Fix the write path before restoring data, or the remediation will be overwritten again.
- Change ownership: set Country to one-way Salesforce → HubSpot, or remove the mapping if Country is not needed in HubSpot. Disable the “Default country” workflow for synced contacts.
- Identify the affected set: use property history or the audit trail to find contacts whose country changed from a Canadian value to US after creation. Do not rely only on the current value, because some legitimate US contacts may also exist.
- Restore from the source: re-sync or re-import the country from Salesforce for the affected records. If a bulk import is used, import into a non-synced staging property first and validate before writing to the synced Country field.
- Prevent recurrence: if a default is still needed for non-synced, manually created contacts, scope the workflow to contacts not created by the integration and use a conditional check against the associated company's country. Prefer leaving the field blank over writing a false default.
- Validate in sandbox: test the workflow with a Salesforce-created contact and a manually created contact, and confirm which value wins after two sync cycles.
3. What governance changes would stop this class of incident from recurring?
Read the worked answer
Create a property ownership matrix and make it operational, not a spreadsheet that nobody reads.
- Label system of record: mark each synced property as Salesforce-owned, HubSpot-owned, or intentionally bidirectional, and name the owner. Country is Salesforce-owned.
- Restrict automation on synced properties: require review before any workflow, default value, or formatting action writes to a property with an external system of record. The review should ask what happens when the record is created by sync and the external value arrives later.
- Test order of operations: sandbox tests should include sync-created records, not just manually created records, and should verify behavior after at least two sync cycles.
- Monitor and audit: alert on bulk changes to synced properties and review the audit log for integration-user writes. A 2,300-record change should have been visible before marketing noticed it.
- Document the rollback: for every automation that writes to a synced field, record how to identify affected records and restore from the source system.
This is a data-ownership problem wearing an automation disguise; the governance fix is to make ownership explicit before the workflow is built.