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:
| Provider | Loop guard |
|---|---|
| Jira | Inbound 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 DevOps | A 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.com | A status-label token recorded at the last sync, plus an idempotent title guard. |
| GitHub | The item's update timestamp, recorded at the last outbound write. |
| GitLab | The 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.
Email support@laya.net — include what you expected, what happened, and a link to the affected board or item so we can help quickly.