How HubConnector resolves conflicts
What happens when the same record changes on both platforms before a sync runs, and how HubConnector decides which change wins.
A conflict happens when the same field on the same record changes on both platforms before HubConnector has a chance to sync it. HubConnector resolves this field by field, not record by record, so two fields on the same record can resolve in different directions.
How a field is resolved
- If the source and target values are already the same, there is nothing to resolve.
- If the field has a master override configured (see How field mapping works), the designated platform's value wins, regardless of which side changed most recently.
- Otherwise, HubConnector uses last-modified-wins: it compares each platform's last-modified timestamp for the record, and the more recently modified side's value wins. If both timestamps are equal, the source side wins.
When a timestamp is missing
If HubConnector cannot compare the two last-modified timestamps, for example because a platform did not return one, the source platform's value wins.
Where to see what was resolved
Every field-level resolution is recorded as a Conflict Resolved event in the audit trail, showing the source value, the target value, the value that was written, and the reason (a master override or last-modified-wins). See Read the audit trail.
Conflict resolution only runs for a field that both platforms already agree exists on the record. Duplicate detection, which decides whether to create a new record at all, is a separate step described in How duplicate detection works.