Help & Documentation

Most conflicts are everyday two-device situations.

• Editing the same item on two devices while one or both are offline.
• Two collaborators changing the same field on a shared project at nearly the same moment.
• Restoring a backup that overlaps with newer edits on the same record.
• Non-overlapping changes auto-merge — only true overlaps reach the modal.
• Internal sync bookkeeping never raises a conflict. The engine's own lineage counter (syncRev) changes on every upload, so two devices that have synced a different number of times always hold different values — that alone is not a conflict and is filtered out of the diff. The same goes for creation and edit stamps of a record: when they differ, the newer one is kept without asking.
• A contact you merged into another one never asks again when the cloud deletes it: it was already hidden, so the deletion is accepted without a dialog.
• Each device keeps its own sync identity, so the same item edited on two devices at once raises a conflict instead of one edit silently overwriting the other.
• A change the server refuses for a shared project (you are a viewer, no longer a member, or the data project was unlinked) never opens the dialog: the server's copy replaces yours on this device. A change refused only because the owner withdrew cloud-sync consent is kept and re-sent every 5 minutes.

On a shared project your edits reach collaborators a moment after you make them. If a collaborator's change arrives in that moment and the page reloads before your edits go out, the two are merged. Your edits are not replaced.

• Changes in different places combine on their own: your new item and theirs both stay, and your edits then sync as usual.
• The same happens when the app turns an upload back because it came from an out-of-date copy.
• If you both changed the same field, the 'Resolve Sync Conflicts' dialog opens. Until you choose, that field shows the collaborator's value, and everything else you changed is kept.
• Nothing from that project is sent to collaborators until you have chosen.

When sync detects an overlap it opens the ConflictResolverModal.

• Timestamps on each side help judge which change is fresher.
• The questions follow the app language and name each field in plain words (Quantity, Notes, Location). A field without a name of its own is shown split into words, for example Sensor Mode.
• A date or time that is the same moment written in two different ways is not a difference and raises no question.
• 'Merge items' is the right call when each side has changes worth keeping in different fields.
• Cloud Safety Backups of both variants (and of the common ancestor, when known) are written as soon as the conflict is raised (backup_conflict_… rows), so a wrong choice is recoverable later.

1. Sync pauses and the ConflictResolverModal opens with a side-by-side diff.
2. Simple view names the cost before you commit: how many cloud changes 'Keep all local data' would discard, and how many changes made on this device since your last sync 'Accept all cloud data' would discard — including changes unrelated to the field on screen.
3. 'Review Field by Field' is the primary button and the only non-destructive route: it keeps both sides. The two whole-record buttons replace one side entirely and cannot be undone.
4. Local (this device) on one side, Cloud on the other. Differing fields are highlighted.
5. Per field: pick 'Keep local' to keep this device's value, 'Use cloud' to take the cloud value, or — for lists — 'Merge items' to keep both sides and de-duplicate.
6. Click 'Apply merge' — until every field has a choice the button counts the fields still pending. The chosen variant is written and sync resumes.
7. If multiple entities conflicted, the modal walks through them one at a time.

A few sync conflicts arrive as two complete versions of a record rather than as a list of differing fields — most often when this device's copy turns out to be older than the last state synced to the cloud, or for record types the app never merges automatically.

• The dialog now splits those two versions into individual fields for you, so 'Review Field by Field' works on them like any other conflict and both sides can be kept.
• The reason the record could not be merged automatically is shown at the top of the dialog — for example that this device's copy predates the last synced state, so parts of it may already be out of date.
• If the two versions differ only in internal sync bookkeeping, there is nothing to choose field by field. The dialog then says so, offers only the two whole-record buttons, and hides the field-by-field tab instead of leading you to an empty one.

Lower the rate by coordinating who's editing what.

• Sync before starting work on a shared project.
• Assign clear ownership — one person edits Camera, another edits Audio, etc.
• Use project chat to announce major changes before making them.
• Avoid editing the same project on multiple devices in parallel without syncing in between.

There is no 'Conflict History' UI, but the data is recoverable via Cloud Safety Backups.

1. Settings → Backup & Data → 'Cloud backups' (must be online).
2. Click 'Load cloud backups' and look for rows whose name starts with backup_conflict_….
3. Two or three rows are written per conflict — local, remote, and base (the common ancestor) when it is known.
4. Pick the variant you actually wanted and click 'Restore'.