Bidirectional syncs inevitably hit conflicts: the same row was changed on both sides between sync runs. How you resolve those changes determines whether you keep a consistent picture or whether bad data creeps in.
Available Policies
- Newer wins (timestamp): The side with the most recent update_at timestamp wins. Simple, but assumes clocks are roughly aligned and only one side is authoritative.
- Source wins: External source always takes precedence. Best when external is the master of record.
- Target wins: ActiveManage always wins. Best when ActiveManage is the master and the external is a stale mirror.
- Field-level merge: Each field merged independently — e.g. customer's address taken from external, phone from ActiveManage. Specify per field.
- Manual review: Conflicts queued for a human to decide. Best for high-stakes data.
Detecting Conflicts
The platform stores a hash of the row at the time of the last successful sync. On the next run it compares hashes — if both sides differ from the stored hash, it's a conflict.
Worked Examples
- CRM ↔ ActiveManage: Field-level merge — “last contacted” field comes from CRM; “preferred contact method” from ActiveManage; everything else newer-wins.
- Inventory sync: Source wins — warehouse system is the source of truth on stock counts. ActiveManage shows the value but never modifies it.
- Partner catalogue: Target wins — ActiveManage is the master; partner side gets clobbered if it edits a product.
- Order status: Manual review for any conflicts on payment_status — too consequential to auto-resolve.
The Manual Review Queue
When the policy is “manual review”, conflicting changes land in a queue. Reviewers see both versions side-by-side and pick the winner per field. Decisions are logged.
Tip: Start with “manual review” for the first week of any new sync. Once you see the conflict patterns you'll have evidence for which automated policy fits.