A one-way sync has a clear story: system A changes, system B follows. A two-way sync has a failure mode one-way syncs literally cannot have. The two directions can trigger each other.

Picture Zendesk tickets linked to Salesforce cases. An agent escalates, which writes a case in Salesforce. Engineering updates the case, which writes status back to the ticket. But that write to the ticket looks like any normal ticket change, so it can fire the escalation sync again, which updates the case, which syncs back to the ticket. Now both records are updating in a tight cycle. A runaway loop is worse than no integration at all.

Two controls stop it.

Actor exclusion: the integration writes through a dedicated user, and each side ignores changes made by that user. When the sync-back updates the ticket, the Zendesk trigger sees its own integration user and does nothing. You're telling each system not to react to itself.

Skip-unchanged guard: before propagating a change, compare the incoming value to what's already there. If nothing actually changed, stop. This catches the echoes that slip past actor exclusion, like a re-save that touches no real field.

The second hard problem is source of truth, and in a two-way sync it usually isn't one system. It's per field. Here, Zendesk owns the customer conversation and original context; Salesforce owns the engineering status and resolution. Neither owns the whole record. You decide ownership field by field, or the two directions quietly overwrite each other and call it a sync.

I wrote up the full design, including the status-mapping decisions between two systems that model status differently, as a spec and runbook below.