Why guard tour apps fail offline, and how Automaata handles it

Security work happens in the places phones hate: sub-basements, concrete garages, mechanical rooms, loading docks under steel decks, and piers where the only signal is the one bouncing off the water. An officer app that needs a connection to record a scan does not record the scan. The gap shows up the next morning as a missed checkpoint on the client's report, and the officer is blamed for the building's construction.

Three ways field apps fail

They queue, but do not store. Many apps hold unsent scans in memory and send them when the signal returns. If the app is killed by the operating system to save battery, which happens routinely on a cheap Android phone after a few hours, the queue dies with it.

They trust the phone's clock. When scans arrive late, the server needs to know when each one really happened. If the app relies on the device time and that time is wrong (a manual setting, a time zone, a phone that has been off), scans land out of order or in the wrong shift. Vendors' own support pages tell customers to set device time to automatic for exactly this reason.

They double-count on retry. The app sends a batch, the connection drops before the acknowledgement arrives, the app sends again. Without a stable identity for each scan, the server now has two of them, and the tour report shows a checkpoint visited twice in one minute.

What the design has to be

1. Write to disk first. Every scan, clock punch, report and photo is written to a local database on the phone before anything else happens. The app can be killed; the record survives.
2. Give every event an identity. Each record carries a unique ID generated on the phone, the device timestamp, and a sequence number that only goes up. Replaying a batch is harmless, because the server already knows those IDs.
3. Let the server decide the time of record. The device timestamp is kept as evidence, but the server also records when it received the event and flags any event whose device clock drifts beyond a threshold. Order is reconstructed from the sequence number, not the clock.
4. Keep mutable things server-side. Schedules, post orders and rates are read-only on the device. Only append-only field events are created offline, so there is nothing to merge and no conflict to resolve.
5. Sync in the background, visibly. The officer sees a count of unsynced records and a timestamp of the last successful sync. A supervisor sees the same per device in the console, so a phone that has not synced in six hours is a thing someone notices before the report goes out.

What to ask a vendor

• Can an officer start, scan and finish a tour with the phone in airplane mode, then sync it an hour later with every timestamp intact?
• What happens if the operating system kills the app mid-shift?
• If the same batch is sent twice, what does the report show?
• Can a supervisor see which devices have not synced, and since when?

A vendor who can answer all four without hedging has built the app for the places your officers actually work.

Sources: TrackTik support, "Mobile App issues with GPS and Checkpoints"; Connecteam's TrackTik review (offline behaviour and app-store ratings); PowerSync and ElectricSQL documentation on offline-first sync.