Guide
Offline is not a feature, it is a requirement
Where field work happens there is no signal: basements, garages, electrical rooms, the end of the driveway. What an app has to do there, and what most do.
Offline is not a feature of a field service app; it is the condition the app has to work in, because the places where the equipment is are the places where the phone has no signal. A gate operator is at the end of a driveway or two levels down in a garage. An access-control panel is in an electrical room with a steel door. The office has signal; the work does not, and an app that needs a connection to save a photo is an app that loses photos.
Where does the signal go?
The same places every time, and every trade has its own list.
For me it is the underground garage, where the operator for the whole structure's gate sits on the lowest level behind concrete; the electrical room, which is a steel box by design; the end of a long rural driveway where the house has a signal and the gate at the road does not; and the plant room in a commercial building where the intercom head end lives next to the fire panel. A plumber's list is basements and crawl spaces. An electrician's is panels, which are in the same steel rooms mine are. A roofer's is wherever the nearest tower is not.
None of those are edge cases. They are the job.
What happens when the app is not built for it?
Three failures, and they compound.
The spinner. The technician opens the job to read the address or the last session's notes and gets a loading indicator, because the list is fetched from the server on every open. After the second time, the technician stops opening the app in the garage and starts asking the office by text from the ramp. The app has trained him out of using it.
The lost photo. The camera uploads at capture. In the garage the upload fails, and depending on the app, the photo is lost, or it is saved with no stamp, or it is saved with the stamp of the moment it finally uploaded, forty minutes later, at street level. All three destroy the one thing the photo was for: proof of when and where.
The silent refusal. The technician writes the note and the quote, and the app says saved. It was not: the write went to the server, the server was never reached, and the app said nothing. The technician finds out in the office, or when the customer asks where the quote is.
Each of those is a decision somebody made to fetch on open, upload on capture and write to the server first, because that is the easy way to build an app in a place with signal.
What does "built for the work" look like?
Three rules, and an app has to follow all three on every screen, not on a special offline mode.
- Every read is local. The list of jobs, the contact, the notes, the calendar, the photos already taken: all of it renders from a store on the phone, instantly, and the app refreshes in the background when it can. There is no spinner where a list should be.
- Every write goes through a queue on the phone. A new session, a note, a photo, a quote, a payment: written to the phone first, queued, sent when there is a connection, in order. Each change is an update to the fields that changed, so it does not overwrite a colleague's edit made in the meantime. A deletion is a marker that syncs like any other change.
- Sync is visible and honest. A screen that shows what is waiting and what failed, and a refused write reported as refused, with the reason. Never a save that did not happen. In Combdex that screen is Settings, Sync: a refused write moves to Couldn't sync with its full payload kept on the phone, to retry, export or discard (sync state).
Photos follow the same rules with one more: the time and place are written at capture, before any upload, so the record says when the photo was taken and not when it reached the server (capturing on site). What to photograph on every job is why that matters.
Combdex is built on those three rules, on every screen, on the mobile app. The offline mobile app page and how offline works describe the mechanics; this guide is why they exist.
What does a session with no bars look like?
The version I want, and now have.
Drive down two levels. Open the calendar; today's session is there because it was on the phone before the ramp. Open the project; the last session's note is there: "Loop detector holding open, delivery truck cracked the saw-cut at the expansion joint, temporary bypass." Start the session. Photograph the board, the detector, the crack; each photo is stamped with the time and the garage. Write the finding. Open a quote for the contact at that Location, pick the loop line from the catalog, add labour, press Save & publish. The publish waits in the phone's queue, behind the save.
Drive up the ramp. At street level the session, the photos, the note and the quote sync in order. The quote is published, gets its number, and its link appears. Text it to the manager from the lot. Open Settings, Sync; nothing waiting.
Nothing in that session required remembering to do anything later, and nothing in it was lost because the garage had no bars. That is the whole requirement.
What is honestly online-only?
A short list of things needs the other side to be awake, and an honest app says which. In Combdex, Dex reads your company's data live, so asking Dex, or drafting a quote from a voice note, needs a connection. Dictation needs the transcription service. The server draws the PDF of a quote or invoice, so the PDF waits for a signal; the quote itself, its edits and its link do not. Changing your password and inviting or changing users are online-only. Connecting a phone system or a website is done on the web. And the customer accepting the quote needs the customer online, because it is their phone.
A social post is not on that list: compose or schedule it in the garage and it is saved and queued, and the app never says it went out before the server has it.
Everything a technician does at the equipment works without a signal. That is the line, and it is the right place for it.
How do you test an app for this before you buy it?
Airplane mode, then a whole session. Open a job. Read the notes. Take five photos. Write a note. Make a quote and send it. Record a payment. Then turn the radio back on and watch what happens.
If a list showed a spinner, if a photo is missing or carries the wrong time, if a save was reported that did not happen, or if there is no screen telling you what synced and what did not, the app was built in an office and not in a garage. Every field app claims to work offline; the airplane-mode session is the only test that finds out. The offline field app page lists what to look for.
Questions people ask
Is a bad signal really that common?
For anyone who works where the equipment is, yes. Operators are in garages and at the ends of drives, panels are in electrical rooms, water heaters are in basements. The office has signal; the work does not. An app has to be designed for the work.
What does offline-first actually mean?
Every screen reads from a store on the phone and every save is queued on the phone. The network is used when it is there and never waited for. The opposite is an app that reads from the server and shows a spinner when it cannot.
What about photos?
They save on the phone at capture with the time and place stamped in, and upload later. An app that uploads at capture loses the photo, or the stamp, or both, when the upload fails in the garage.
How do I test an app for this?
Airplane mode, then run a whole session: open the job, take photos, write the note, make the quote. Then turn the radio on and watch. If anything was lost, refused silently, or has the wrong time on it, the app was not built for the work.