Mobile and offline
Offline-first is not a feature, it is an admission
Every field tool claims offline support. The interesting question is what the software does when two technicians edit the same closure from two different dead zones.
Connectivity is not the hard part
Caching a map and queueing a form is a solved problem. The hard part starts on the second sync, when the queue contains two edits to the same object made hours apart by people who could not see each other's work.
A tool that silently takes the last write has not solved offline. It has moved the failure somewhere quieter, where it surfaces weeks later as a capacity discrepancy nobody can explain.
Questions worth asking a vendor
- What happens on conflict?
- Last-write-wins, a merge, or a human review queue. All three are defensible. Silence is not.
- What is the unit of sync?
- A whole work order, or the individual fields inside it. This decides how often two crews collide.
- Can the crew see queue state?
- A technician who cannot tell what has synced will re-enter data defensively, which creates the duplicates you are trying to avoid.
The sync worked perfectly. That was the problem, it overwrote six hours of splicing without telling anyone.
Design for the reconnect, not the disconnect
Treat every offline edit as a proposal against a known version of the object. On reconnect, apply what is unambiguous and route the rest to a person, with both versions and the evidence attached.
It is slower to build and it is the only version that keeps the network record trustworthy after the second truck arrives.