Offline Sync Conflicts and How to Prevent Them
Offline sync conflicts and how to prevent them
An offline sync conflict happens when two devices change the same record while disconnected, or when the same person or household is registered twice, and the server has to decide which version wins. Most tools apply updates in the order they arrive, so the last upload quietly overwrites the earlier one, or both copies survive as duplicates. You prevent conflicts mainly with process: one owner per record, IDs generated on the device, fixed form-update days and a daily reconciliation check. This guide explains how. For tool choice, see our comparison of the best offline data collection apps for NGOs in 2026.
Why conflicts happen in field programmes
| Cause | What it looks like | How common in our projects |
|---|---|---|
| Two workers update the same household offline | One worker's changes vanish | Common in case-tracking programmes |
| Same person registered twice | Two IDs, split history, inflated counts | Very common |
| Old form version on some devices | Missing fields, failed imports | Common after mid-cycle edits |
| Partial or repeated uploads | Duplicate submissions | Occasional on weak networks |
| Reassigned cases | Old and new worker both act on a case | Common after staff turnover |
| Sync between two systems | Counts differ between app and dashboard | Common once an MIS is added |
The last row is easy to miss. In one project, a maternal and child health nonprofit collected facility checklists in Ona and synced them into a Zoho Creator programme system. High-volume syncs needed a change to how data was retrieved, and duplicate source records made checklist counts differ from activity reports and dashboards. Nothing was wrong with either app. The work was agreeing KPI definitions, tracing duplicates back to the source, and running reconciliation tests between systems.
How tools handle conflicts
- Survey tools (Kobo, basic ODK forms): each submission is a new record, so conflicts show up as duplicates rather than overwrites.
- ODK Entities: Central detects when an update was based on an older version of an Entity and flags it. Updates are still applied in the order received; office staff review flagged conflicts using the full history. Entity updates from submissions arrived in Central v2023.5.
- Case-based tools (CommCare, Avni, SurveyCTO case management): cases have owners, which limits who can update what.
- Custom MIS apps (such as Zoho Creator): you design the rules, which means you must decide them.
No tool removes the need for clear rules on the ground.
Seven rules that prevent most conflicts
- One owner per record. Each household or case belongs to one worker. Others add visit notes as separate child records, never edit the parent.
- Generate IDs on the device. Use the app’s unique ID (UUID) plus a readable prefix such as district and worker code. Never ask workers to type serial numbers.
- Search before you register. Make the registration form show matching names in the worker’s area first. Cache the list for offline use.
- Append, don’t overwrite. Store each visit as a new record linked to the case. History survives, and conflicts become rare.
- Fixed form-update days. Publish form changes on one day a week and check devices have the new version before field days.
- A sync habit. Workers sync at least daily when they reach network, and always before handing a case to someone else.
- A reassignment ritual. When a case moves, the old worker syncs first, then the case is reassigned on the server, then the new worker syncs.
Worked example: a daily reconciliation check
For a programme with 50 field staff syncing into an MIS, a 20-minute daily check catches most problems before they reach a report.
| Check | Query | Action |
|---|---|---|
| Possible duplicates | Same name + same village + birth year ±1 | Review queue; merge, don't delete |
| Old form versions | Submissions where form version is not the current one | Call the worker; update the device |
| Orphan visits | Visit records with no matching case ID | Link or return to the worker |
| Stale updates | Updates flagged by the server as based on an old version | Supervisor decides with field worker |
| Count match | Total submissions in collection tool vs records in MIS for yesterday | Investigate any gap above 1% |
Keep a short conflict log: date, record ID, cause, decision, who decided. After a month, the log tells you which rule is being broken and where retraining is needed.
When conflicts mean you’ve outgrown your tool
If you are spending hours a week merging duplicates in a survey tool, the issue may be structural: you are tracking people over time with software built for one-off surveys. That is the point to look at a beneficiary management system with real case ownership. Teams on Kobo can compare options in our KoboToolbox alternatives guide. And before rolling out, make sure the devices themselves are ready; see choosing devices for field data collection in India. If the cleanup is part of a larger move off spreadsheets, our 5-step digital transformation guide for nonprofits helps sequence the work.
Not sure your field set-up will survive the next survey round? Take the free nonprofit technology assessment. Start the free technology assessment →