Our CRM and field service system keep overwriting each other. Why?
You have a two-way sync with no conflict rule. System A writes to B, B treats the update as a genuine change and syncs it back to A, and each side sees the other's echo as new information. Fix it three ways: declare a system of record per field rather than per record, tag writes with their origin so a system ignores its own echoes, and compare values before writing so an unchanged field never generates an update.
How the loop forms
Two-way sync is usually built as two one-way syncs pointed at each other. Each one is correct in isolation. Together they form a cycle, and the cycle has no natural stopping point.
The classic symptom is a record whose modification history shows the two systems alternating every few seconds, sometimes for hours. Less obviously, it also shows up as a field that reverts: someone corrects a phone number, it looks right, and an hour later it is wrong again because the other system won the last round.
Ownership belongs at the field level
Record-level ownership is too coarse. The field service platform is the right authority for service address, job history and completed work. The CRM may be the right authority for marketing consent, lead source and campaign membership. Neither should own the whole customer.
Write the ownership map down as an actual table: field, owning system, sync direction, conflict rule. It takes an afternoon and it resolves nearly every argument that comes up later. Deciding this before anything is built is one of the first things a serious integration engagement establishes.
Three mechanisms that stop echoes
- Origin tagging. Every write carries a marker identifying the system that originated it. A sync that sees its own marker on an inbound change ignores it. This is the most reliable of the three.
- Compare before write. Read the current value, and if it already matches, do nothing. No write means no change event means no echo. It also cuts API call volume substantially, which matters when you are working against rate limits.
- Watermarks with skew tolerance. Track the last successfully processed modification timestamp per system and only process newer changes. Useful, but clock differences between systems make it dangerous as the only defense.
The metric that catches it early
Count modifications per record per day and compare against how many real edits anyone made. If a record shows dozens of updates and no human touched it, you have a loop, and it will be consuming your API quota as well as corrupting data.
Alert on that ratio rather than waiting for someone to notice a reverted phone number. Silent sync failures and silent sync loops are the two most common ways an integration degrades without anyone filing a ticket, and both are cheap to monitor once you decide to. That monitoring is part of what running an integration platform responsibly means.
Topics: sync · integration · system of record · data hygiene
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.