In this guide 6 sections
Field service apps lose data when they treat the network as always there, and a job card saved without signal is sent once and never retried. A good app saves to the phone first, queues every change, retries with duplicate checks and resolves clashes by a written rule.
The app sends before it saves
Many apps post a job card straight to the server when the technician taps Complete, and in a lift shaft or basement plant room the request simply dies. A green tick may still show.
The technician drives to the next site, the card never reaches the office, and nobody finds out until the customer asks for the service report, sometimes weeks later.
The cure is plain. Write to the local SQLite store on the phone first and send afterwards, because the phone must hold the truth until the server confirms receipt of every record.
- Job card status changes
- Meter and gauge readings
- Parts used from the van stock
- Time on site and travel time
Photos and signatures fail in their own ways
A photo of a nameplate is large, and a customer signature is a small image that must arrive with the card it approves. On a weak connection the upload stalls halfway through the nameplate photo and the app gives up without telling the technician, who has already driven away.
Some apps send the card without its photo, or the photo alone, leaving the office with an orphan image and no way to tell which job it belongs to.
A sound app compresses the photo on the phone, uploads in pieces, resumes where it stopped and ties every file to a job reference before it leaves the handset.
- Compress the photo on the phone before upload
- Resume a stalled upload, do not restart it
- Attach the job reference to the file itself
- Keep the signature and its job card in one package
Retries create duplicates
Now the opposite fault. The app sends a card, the server saves it, but the reply is lost in a dead patch, so the phone thinks it failed and sends again. Two reports and two invoices follow.
The fix is an idempotency key: each submission carries a unique identifier made on the phone, so when the server sees the same identifier twice it keeps one copy.
Retries should also back off, because a phone hammering the server every second in poor coverage drains its battery and wins nothing.
Two edits to one job need a rule
A dispatcher reassigns a job while the technician, offline in a basement plant room, closes it, and when the phone reconnects both changes arrive and someone has to win.
Decide the rule before the first release. Technician edits to the work done usually win, dispatcher edits to schedule and assignment usually win, and anything that cannot be settled by field is flagged for review.
A silent last-write-wins rule is the worst choice, because it overwrites a signed completion with a stale status and no one notices until the customer disputes the visit.
- Field ownership: who may change which field
- A visible conflict list for the back office
- A history of every change with time and device
- A clear message to the technician when a change was rejected
Test it the way a technician works
Do not test on office wifi. Put the phone in aeroplane mode, complete three jobs, add photos, kill the app, restart the handset, then reconnect inside a lift and count what arrives.
Have the vendor demonstrate the sync queue on screen, because technicians should see how many items are waiting rather than guess, and a pending counter ends many arguments.
Before you accept a build, run the same drill with your slowest, oldest handset and write down every item that went missing or doubled.
Offline sync test sheet
One line per test. Lines cover aeroplane mode job close, photo upload on a throttled link, signature capture, app killed mid sync, duplicate submit and dispatcher edit against technician edit. Each line records the handset model, the steps taken, the expected result, the actual result, and a pass or fail mark that the vendor and your team both sign.
Open a blank worksheet to printQuestions owners ask
How do I know if my app is losing jobs?
Compare jobs closed on technician phones with the cards that reached the office, because a gap or two records for one job reference shows the sync is failing.
Does offline mode need a native app?
Not always, since a well built installable web app can queue changes offline, although hardware access, large photo batches and background sync on iPhone can favour a native app.
Can lost photos be recovered?
Sometimes. The photo survives if the app keeps the file on the handset until the server confirms it, and is gone if the app deletes it after a failed send.
What should the technician see on screen?
Show a count of items waiting to send, a clear sent state and a red flag for anything rejected, because silent success messages are what hide this problem.