Conflict Resolution — Handling simultaneous updates

When multiple users or a device and the server update the same record around the same time, a conflict can occur during synchronization. This article explains approaches used to resolve conflicts and recommended everyday procedures for users and admins.

Note: The repo documents the offline queue and sync; exact server-side conflict policy (for example last-write-wins, server-based merging, or field-level merges) is a product decision. If you need the project’s precise conflict policy, consult the engineering team or the server-side docs. :contentReference[oaicite:7]{index=7}

Common conflict scenarios

• Two technicians update the same job fields (status, notes, or assigned technician) while one is offline. When the offline device syncs, the server must decide how to merge or reject updates.
• A job is deleted on the server while a technician creates or edits attachments locally.

Typical resolution strategies (general)

Below are common strategies teams adopt; the repo’s offline architecture is compatible with any of these depending on server-side design:

1. Last-write-wins (timestamp-based): The server accepts the update with the latest timestamp. Simple but can overwrite important changes.
2. Versioning / optimistic locking: Each record has a version; updates specify the version they were based on. If the version is stale, the server rejects the update and returns a conflict error to the client. The client can then prompt the user to merge or retry.
3. Field-level merging: The server merges non-overlapping field changes and detects conflicts only when the same field is changed by both sides.
4. Manual resolution UI: When an application cannot safely merge changes, present the user with a conflict UI showing both versions and let them choose or copy changes.

Recommended approach for CJH users & admins

• For support: If a client reports data was overwritten, gather logs and timestamps of the conflicting operations (see Logs & Diagnostics). That will help engineers determine what strategy the server used and whether manual recovery is required.
• For technicians: If asked to reconcile a conflict, avoid making repeated blind edits; instead, capture the current server state (open the full job) and re-enter only missing or corrected information.
• For implementers: Prefer designs that minimize conflicts (e.g., avoid letting multiple people concurrently edit the same fields, use locks or assign single dispatchers for critical fields). Where conflicts are possible, implement optimistic locking or a user-facing merge step.

Client-side behavior on conflict

• If the server rejects an item due to a conflict, the client should surface an informative error and retain the queued item for retry after user action or manual reconciliation. Because CJH keeps queued operations durable on the client, users won't lose their inputs; they will need to resolve the conflict or retry.

Need exact policy? If you require the application’s precise conflict-handling rules (for example, “does the server do last-write-wins?”), I can locate and summarize the server-side code or API docs if you’d like me to check the backend implementation.

Updated on: 10/01/2026