In this guide 6 sections
Entries go missing because the app saves straight to the server instead of the phone, so a dropped signal makes the save fail quietly. The fixes are local storage, a visible queue of pending entries, honest failure messages and a rule for two people editing one job.
The save button talks to the server, not the phone
Most lost entries start with one design choice. The app sends the form to the server the instant the technician taps save, and waits for an answer.
In a basement plant room, a parking structure or a highway stretch, that request never arrives. What happens next depends on the screen. Some apps spin forever. Others close the form and flash a green tick anyway, which is worse. The technician walks on, sure the reading is safe. It is not.
A sound field app writes the entry to storage on the handset first and sends the server copy second, retrying until the server confirms. That order is the difference between a delay and a loss.
- Form data held on the handset until the server confirms
- Photos stored as files, not only as links
- Signatures saved with job number and time
- Entry kept after the app closes or the phone restarts
Silent sync failures
Even apps with local storage lose work. A background sync job hits a timeout while uploading a large photo, restarts from zero twice, then gives up. Nothing tells the user. Nothing tells the office either.
The entry sits on the phone while the office sees an empty job. Common causes include an expired login token, a handset that clears app memory to save battery, and an upload that restarts after every interruption instead of resuming.
Ask the developer to show the sync log for one failed entry. No log, no answer. A team that cannot trace a single lost reading cannot promise the next one will arrive.
Two people, one job, one clash
A supervisor corrects a meter reading from the office at ten. The technician, offline since nine, saves a different value at eleven. Once the phone reconnects, one of them wins, and nobody is told.
Settle the rule before it happens, preferably in the first week of the build. Last write wins is simple but destroys data. A better design keeps both versions, flags the job for review and lets a named person choose, while photos and signatures are never replaced, only added.
Record who changed what, from which device and at what time. That history ends most arguments in minutes, and it shows which handsets cause trouble.
What the screen should tell the technician
People cannot fix what they cannot see. Show a pending count on the home screen. Mark each job as saved on phone, sent or failed, using words as well as colours so that a glance in bright sunlight still works.
A failed entry needs a retry button and a reason in plain language, such as “photo too large for this network”. A badge reading “3 waiting” changes behaviour. Technicians linger at the gate until the count reaches zero.
Block logout and reinstall while entries are pending. A forced app update, or a technician clearing storage to make room for photos, has wiped more field data than any network fault ever has.
- Pending count on every screen
- Per-job status: on phone, sent, failed
- Retry button with a stated reason
- Warning before logout or reinstall
How to find out what is already lost
Compare counts. Take one week of closed jobs from the office system and set it against the forms technicians say they filled. Gaps by person point to a handset problem, whereas gaps by site point to coverage.
Next, ask three technicians to switch on airplane mode, save a job with a photo, walk across the car park and reconnect. Watch what happens on their own phones. A test device proves little.
List every loss point you find and send it to your developer. Ask for the worst to be fixed first, then repeat the airplane-mode test and confirm the pending count behaves as promised. Keep the tracker open until three clean weeks pass, so a fix that works in the office is proven in the field.
Field sync loss tracker
One tracker page gives every missing entry its own line. Columns hold date, technician, site, job number, entry type (reading, photo or signature), phone model, signal at the site, what the screen showed, and how the loss was found. A summary block counts losses by site.
Open a blank worksheet to printQuestions owners ask
Can we fix this without rebuilding the app?
Often, yes. Local storage, a pending queue and retry logic sit in the save and sync layer, not in every screen. Ask your developer for a separate estimate on that layer alone.
Why do photos fail more often than text?
A photo is far larger than a form entry. On a weak network the upload times out and restarts. Shrinking the image on the phone and sending it in small resumable parts helps a great deal.
How do we stop two people overwriting each other?
Keep both versions and flag the job for review. Store the editor’s name, device and time with every change. Allow silent overwrites only where either value is harmless.