Appearance
Offline mode and poor reception behavior
Partial
GoSafety supports offline and poor-reception behavior, but not every workflow behaves the same way. The current product has strong offline support for some field captures and only partial offline support for others.
Snapshot
| Workflow | Current offline behavior |
|---|---|
| Time cards | Strong offline support after login. Clock-in and clock-out write locally first and sync later. |
| PDF submissions | Queue-first fallback on transport or offline failure, then later sync. |
| Safety checklists | Local pending drafts and pending media handling exist; some helper lookups still need network. |
| AI transcription and AI extraction | Network required. |
| First login | Network required. |
What it is
This page explains what a crew can still do when reception is weak or missing, what sync behavior exists after service returns, and which parts of the product still depend on live connectivity.
Who uses it
- Foremen and workers in low-connectivity jobsite conditions.
- Safety managers evaluating whether a workflow can be trusted in the field.
- Office admins who need to understand when records will appear after crews reconnect.
Time cards
- Clock-in and clock-out write to local storage first.
- Sync runs later in the background.
- Client entry IDs make clock-in and clock-out retries idempotent.
- First login still requires connectivity.
PDF submissions
- If a transport or offline error occurs, the iOS app stores the submission in a durable local queue.
- The server remains the canonical source of truth once sync succeeds.
- Pending items appear in My Files until they sync.
- PDF preview or share actions stay disabled until the synced server record exists.
Safety checklist drafts and evidence
- Pending drafts can be saved, resumed, renamed, and discarded locally.
- Media uploads continue with retry behavior when possible.
- GPS capture itself can succeed offline, but address and weather lookups often need network access.
- The worker can still type or edit address and weather text manually before submission.
Sync triggers after service returns
- App becomes active.
- User authenticates.
- Connectivity changes back to online.
- Manual sync actions in the app.
Outputs and downstream effects
- Queued records eventually become canonical server records after sync succeeds.
- Local draft rows remain visible so field users do not lose context while offline.
- The office web app only sees the server-side version after sync.
Practical construction examples
- A worker clocks in and out in a dead zone and the time entry syncs when the phone reconnects.
- A field user saves a PDF submission locally, sees it as pending sync, and later gets the final PDF once upload completes.
- A foreman captures GPS and types weather manually when lookup services are unavailable.
Limitations and notes
- Offline does not mean every feature is fully local-first.
- AI dictation and transcript extraction need network access.
- Address and weather lookup are helper features and usually need network.
- The current codebase does not replace server review with a full cross-device offline office workflow.