Two-way sync
Two-way sync is an integration in which a record held in two systems is kept consistent in both directions: a change made in either system, such as a status update, is reflected in the other without anyone re-entering it. In bug reporting it links a report on a feedback board to its issue in a project tracker, so that a status change on either side moves the other.
The longer version
The mechanism is a mapping and a pair of listeners. When the report is pushed to the tracker, the integration stores the pair of identifiers, the report on one side and the issue on the other. A mapping table says which states correspond: the board's QA stage to the tracker's In Review, Done to Closed. Each system notifies the other of a change, usually by webhook, the integration translates the change through the mapping and applies it to the twin, taking care not to echo it back. Fields that exist on one side only, such as an internal priority or the evidence attachments, stay where they are.
The phrase also names file and database synchronisation, where two copies of the same data are reconciled, and calendar or contact sync between devices; the mechanics overlap, and this page is about workflow records. The nearest contrast is one-way sync, or a push: the report creates the issue and is never updated by it, so the tester closes the report by hand when the developer closes the issue, or forgets to. One-way is simpler and enough when one system is plainly the source of truth. Two-way is needed when two groups work in two tools and each needs to see the other's decision.
A conflict is the same field changed on both sides between two syncs, and the rule that settles it is a declared authority: one system owns the field and its value wins every tie. An integration with no declared authority picks a winner anyway, by timestamp or by arrival order, and that is the failure: clocks disagree, webhooks arrive out of order, and the ticket flips between two states every minute. An unmapped state is a tracker column the mapping never named, so the issue moves, the report does not, and the two drift apart while both look current. The safeguards are a mapping that covers every state, an authority per field, and a visible last-synced time on the record.
Common questions
What is the difference between one-way and two-way sync?
One-way sync pushes a record from a source system to a target and never reads back, so changes made in the target stay there. Two-way sync listens on both sides and mirrors changes in either direction through a mapping. One-way is enough when one tool is the record of truth; two-way is needed when two teams each work in their own tool and both need the current state.
What happens when the same field changes in both systems?
One system is declared the authority for that field in advance, and its value wins the tie; the other side is overwritten and the record says so. Letting the most recent change win by timestamp, or by whichever webhook arrived last, is the failure mode rather than a rule: clocks disagree, deliveries arrive out of order, and the two systems overwrite each other in turn until the record flips between states.
Does two-way sync copy everything between the two tools?
No. A two-way sync copies the fields that are mapped, typically title, status and comments, and leaves the rest where it lives. Internal notes, evidence attachments and a team's own priority field usually stay on one side on purpose, because the other tool has no place for them or the other audience should not see them. The mapping is a decision, not a default.
How are statuses mapped in a two-way sync?
Through a table the team fills in once per tracker: each stage on the board is paired with a status in the tracker, and the pairing is read in both directions. Several board stages can point at one tracker status when the tracker is coarser, and a tracker status with no pair is left unmapped on purpose, so a move into it changes nothing on the other side. Every state on both sides is either mapped or deliberately not.
Is two-way sync real-time?
Near enough for workflow records. Each system sends a webhook when a record changes, and the integration applies the change to the twin almost immediately; where a tool offers no webhook, the integration polls on a schedule and the lag is the polling interval. A visible last-synced time on the record tells the reader whether what they see is current, which matters more than the exact delay.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.