Overview
Offline-first means records regularly spend time queued on a phone before they land — which is normal, not a fault. This article is about reading the difference between normal (pending, waiting for coverage) and needs action (failed, or something genuinely stuck), and what to do at each branch.
Reading the sync state
The Profile screen's sync card is the one-glance answer: counts of pending, syncing, and failed records. Tapping through opens the detail, and the failed uploads screen (via Alerts) lists anything that needs a human.
| State | Meaning | Action |
|---|---|---|
| Pending | Queued, waiting for coverage or its turn | None — it uploads on the next sync |
| Syncing | Uploading now | None |
| Failed | Retries exhausted, or the server said no | The failed-uploads screen — Resend/Remove |
| Synced | Landed | None |
"Pending" for a long time
Pending means the phone hasn't had a good sync window since — which in a black spot can legitimately be days. The record is durable (encrypted on the phone) and uploads with its original performed-at time. To move it along: get coverage, open the app, pull to refresh. Compliance-wise, a pending check is a recorded check — see Checking Your Inspection History.
"Failed" records
Failed means retries ran out or the server rejected it — surfaced deliberately instead of silently dropped:
- Resend after a transient cause (a long outage) usually just works.
- A record that fails identically on every resend was rejected for a reason — the row says why. The common ones: the machine was reorganised out from under it (group/classification changed), or a licence lapsed between the action and the sync. Fix the cause, resend; genuinely stuck ones go to support — Remove is last resort, since removing discards the record.
Office changes not reaching the field
The reverse direction — a new checklist, a licence change, a reassigned machine not showing on a phone — is the same story backwards: the phone applies changes on its next sync. Pull to refresh with coverage. Sign-out/in is never required for data freshness.
The suspension case
If your organisation's subscription lapses into suspension, field records queue rather than fail — deliberately, so a billing problem never discards a safety record. They land when the account recovers. See What Happens If a Subscription Lapses.
Edge cases
- Two phones on one machine — each syncs its own work; phone A's offline defect reaches phone B only after both have synced.
- Force-closing mid-sync is harmless — the queue is durable and resumes; there's just no reason to do it.
- Reinstalling the app — sync first (the pre-sign-out flush pushes queued records); a reinstall with unsynced work should be a support conversation, not a reflex.
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| Records pending for days | No usable coverage window since | Coverage + pull to refresh; they land with original timestamps |
| A record marked failed | Retries exhausted or rejected | Failed-uploads screen — read the reason, fix, resend |
| The same record fails every resend | A real rejection (group/licence changed) | Fix the cause; support if unclear — don't Remove reflexively |
| Office edits not on the phone | No sync since | Pull to refresh |
| Everything queues, nothing ever sends | App is offline-blocked (old version?) | Check for an update-required prompt — see Installing the App |