Field work happens in basements, rural sites, and buildings that block signal. The mobile app is built on the assumption that connectivity is intermittent: everything a crew needs lives on the device, and the network is only required to download forms and upload finished work.
Forms are cached on the device
When a device syncs, it downloads the current published version of every form the signed-in user is assigned to collect with and stores it in a local database on the device. Older versions a record still depends on come along too — a dispatched record captured under version 2 arrives with version 2's definition, so it opens correctly offline (see form versions). From that point, opening a form, filling it out, and saving drafts require no connection at all. A first sync runs automatically at sign-in, so a new user's forms are on the device before they reach the field.
Form edits you make in the dashboard never affect devices mid-shift — devices only receive a new version when you publish and they next sync. See data model for how drafts and published versions are kept separate.
Drafts save as you type
A draft in progress is protected three ways:
- Timed auto-save — 30 seconds after the last change, the draft is written to the device's local database.
- Save on backgrounding — switching apps or locking the screen saves immediately.
- Save on navigating away — leaving the form saves immediately.
Because drafts live in the on-device database, not in memory, they survive an app restart. If the app is killed or the phone dies mid-inspection, the draft is there on relaunch, current to within the last auto-save. Drafts also survive being offline indefinitely — there is no expiry that discards unsynced work.
Submitting while offline
Submitting a record queues it on the device and starts the upload right away when the phone has a connection. Offline, the record waits in the queue, and the app uploads it the next time it is opened with a connection. The user can keep capturing new records while earlier ones wait.
Nobody has to remember to sync. The sync icon in the header carries an amber dot for as long as anything is still waiting to upload, and the icon can be tapped — or the list pulled down — to try again on demand. On the Records screen, a submitted record shows an upload-pending cloud icon; only synced means the data has reached the platform.
Each upload carries a SHA-256 checksum of the field values, stored with the record as an integrity fingerprint. The record lands with its full audit metadata — submitter, timestamp, device details, and GPS where the form captures it — as described on the security page.
Why there are no merge conflicts
Sync systems usually get complicated when two parties edit the same thing. FieldScroll avoids the problem structurally: records are append-only submissions. Each record is a new row created by one device, tied to the published form version it was captured against — two crews can never edit the same unsynced record, so there is nothing to merge and no conflict dialog to resolve in the field. A queued record either uploads and is confirmed, or stays on the device and retries; it is never half-applied.
The one case where a submitted record goes back to a device — dispatch — keeps the same property a different way: a dispatched record is checked out to exactly one user and locked for everyone else until they resubmit it or the dispatch is revoked. One writer at a time, so still nothing to merge.
The trade-off is honest: this model fits data capture, where each submission is new. It is not a collaborative-editing model, and we do not present it as one.
For the day-to-day mobile experience — signing in, syncing, working through assigned forms — see the mobile app page.