Skip to content

Conflicts, loops and safety

How Laya resolves simultaneous edits, prevents sync loops and duplicates, and what happens to deletes in each direction.

Last updated

On this page

Two systems editing the same work raises obvious questions: what if both sides change at once, what stops an edit bouncing back and forth forever, and what happens when something is deleted? Laya's answers are deliberately conservative: the most recent edit wins, sync never loops, and nothing you did not delete yourself is ever destroyed.

Last writer wins

When both sides change the same item, the most recent edit wins. An inbound change from your tool is skipped if the Laya item was modified more recently, and an outbound push that has been overtaken by a provider-side change is surfaced as a conflict rather than silently overwriting newer work.

Echo guards: how loops are prevented

When Laya pushes an edit, the provider's webhook or poll soon echoes that same change back. Laya has to recognise its own write, otherwise the echo would trigger another push and loop forever. Each connector carries its own guard:

ProviderLoop guard
JiraInbound changes are applied with an internal suppression flag so they never trigger a push back, and descriptions are compared on canonical content before writing.
Azure DevOpsA revision token recorded at the last sync. Writes also carry a revision check, so a stale write is rejected by Azure DevOps instead of overwriting newer work.
monday.comA status-label token recorded at the last sync, plus an idempotent title guard.
GitHubThe item's update timestamp, recorded at the last outbound write.
GitLabThe item's update timestamp, recorded at the last outbound write.

When a conflict is detected

If Jira changes while a Laya update is still in flight, the link is marked as a conflict: the card's badge reads conflict with the explanation 'Jira is authoritative', and the connection records 'Jira changed while a Laya update was in flight.' The next inbound refresh brings the item back in step. Azure DevOps behaves similarly in effect: a stale write fails its revision check, the failure is recorded in the sync log, and the next poll reconciles both sides.

Duplicate prevention

  • A Laya work item links to at most one external item.
  • The same external item can appear on several Laya boards at once — each board gets its own link. Importing an item onto a second board creates a new link; it never steals the first.
  • The Jira import wizard is retry-safe: a deduplication index means running an import again does not create duplicate items.
  • Auto-create new issues on master boards is idempotent and race-guarded, so a burst of events cannot create the same card twice.

Deletes, per direction

Deleted in your tool

  • The mirrored card is removed from the connected board — instantly for Jira when the deletion event arrives, or when the board next refreshes.
  • Linked Laya items are never deleted by sync: no inbound event deletes a Laya work item.

Deleted in Laya

What Laya never does

  • Never migrates or moves your data — mirroring streams a live copy while your tool remains the system of record.
  • Never deletes a Laya work item in response to a provider event.
  • Never rolls back an edit you made in Laya because the push to your tool failed.
  • Never writes a master-board status-mapping pin back to your tool — pins are display-only.
  • Never discards your work on disconnect: native boards and imported items survive, and only the mirrored copies are removed. See Disconnecting safely.
Still stuck?

Email support@laya.net — include what you expected, what happened, and a link to the affected board or item so we can help quickly.

Contact support