In this guide 6 sections
Four causes explain most vanished entries. Two people edit one record. Device clocks disagree. A queue is wiped at logout. The server rejects a record and the app hides the error, which an airplane mode test with logs open will expose in minutes.
Two people edited the same record
A supervisor and a technician both open job 4471 while offline; the technician adds a part used and the supervisor changes the status. Both come online. The server keeps whichever edit arrives last, and the other change disappears without any warning, error or log line that either person could see.
This is the commonest cause of missing entries, and it is no bug in the usual sense but a missing rule about what happens when two edits meet. Someone must choose that rule.
Ask your developer which rule applies today. The answer is often last write wins, simply because nobody chose anything else when the sync code was first written and tested.
- Last write wins
- Merge by field, so each change survives
- Flag the clash and ask a person
- Lock the record while one person edits
Device clocks out of step
Many apps pick the winner by the handset’s timestamp, so a phone with a wrong date or a reset battery clock carries a stamp from the future. Its edits beat every correct one.
Test it. Set one test phone ten minutes ahead, edit a record offline, sync, and see whether it overrides a newer change from a phone with the correct time. If it does, the server must stamp the arrival time itself or use a version number, and the phone clock should never decide a winner again.
A version counter is simple. It needs no clock, and the server simply rejects any edit made against an old version instead of silently overwriting the newer record that another person saved.
Queued uploads dropped on logout
Offline entries wait in a queue in the phone’s SQLite store, and some apps clear that queue with the session when a worker logs out or an update installs. The entries were never sent. Now nothing remains anywhere.
Run this test. Create three entries in airplane mode, log out, log in as someone else, switch the signal on and watch what the app does with the queue. It should warn that three entries are unsent and refuse to wipe them until they reach the server, whoever logs in next.
On shared handsets this matters more. The queue should belong to the user who created it, and it must survive logout, token expiry and app updates until every entry reaches the server.
- Warn before logout when entries are unsent
- Keep the queue after an app update
- Tie each entry to its author
- Retry with a visible counter
Server rejections the app hides
Sometimes the server refuses an entry with a 400 or 422 response because a field is empty, a customer code was deleted or a photo is oversize. When the app swallows that error, the worker sees a green tick, moves on to the next job, and never learns the record was refused.
Ask for a sync log that shows every record with its result and reason, then check the server’s error log for rejected requests from the same hour. Repeated identical messages are the clue.
Each refused entry should stay on the phone, marked in red, with a plain line saying which field to fix and who can approve an override. Never discard one silently.
Tests and rules to request before the next release
Write the airplane mode scenarios down. Edit offline then sync. Two phones editing one record. Logout with a queue. An expired token, a very large photo and a phone left offline for a week complete the list, and each one runs before every release.
Have the developer put the conflict rule for every record type in one table: job status by manual review, notes merged by field, part quantities by version number.
Next step: choose one real lost entry from the past month, trace it through the sync log, and find which of the four causes removed it.
Offline sync test sheet
A single table of airplane mode scenarios, one per row: offline edit, two-phone clash, wrong clock, logout with queue, expired token, oversize photo and week-long offline. Columns hold the steps, the expected result, the actual result, the sync log line and a verdict for each scenario, so every test leaves a written trace. Below the table, a separate block names the conflict rule for each record type, from job status to part quantities and photo attachments.
Open a blank worksheet to printQuestions owners ask
Can offline apps ever be fully safe from conflicts?
No. Clashes stay possible whenever two people edit one record together, so the achievable goal is a chosen rule for each record type and a visible report of every clash.
How do we know an entry was lost and not never made?
Compare the device’s database or queue with the server log, because an entry present on the phone but absent on the server was either never delivered or was rejected.
Should the phone clock be trusted?
No. Use the server’s arrival time or a version number per record, since phone clocks drift, get changed by hand and reset when batteries die.
Is a full resync the fix?
A full resync hides the symptom and can overwrite good server data with stale copies from a handset that sat offline for days. Find the cause first. Then resync only the affected records.