Separate connectivity from location
A phone without internet may still obtain a GPS fix. A phone in a basement may struggle to obtain a useful location even when some internet is available. An offline attendance feature addresses delivery; it does not necessarily remove the camera, location or identity requirements for capture.
An onboarded Attendify personal device can store a capture and its evidence locally. Initial onboarding and replacement-device authorization need a connection. The shared kiosk has a different online-only identification flow.
Follow all four states
Scroll the table sideways to read all columns.
| Stage | What exists | What the dashboard knows |
|---|---|---|
| Capture | Event time and evidence on the device | Nothing new until communication |
| Pending | Local queue and retry state | Still the last received attendance |
| Accepted | Server attendance record | Accepted event becomes available |
| Terminal rejection | Worker receives an error; local capture/selfie removed | No accepted attendance from that capture |
The phone can show a pending count. A central dashboard cannot know a capture stored only on a disconnected phone. Avoid reading a missing received checkout as proof that the worker stayed on site or did not work.
Preserve the event’s identity
Attendify assigns a client event identifier and the server deduplicates accepted submissions using that identity. Retrying the same event should not create several records merely because the connection is unreliable. This is different from a supervisor independently entering a correction for an event that later arrives.
Capture time and server receipt time are distinct fields. A delayed accepted event retains its capture timestamp, which allows the delay to be understood. That timestamp is still supplied by a device; it is not an independent guarantee of an untampered clock.
Check changes that happen before sync
A worker may be reassigned, a template reset or an attendance requirement changed while a capture is waiting. Attendify validates using the server-side data available to that flow. It does not promise a complete immutable snapshot of every capture-time policy.
A network failure keeps the capture queued. A terminal application rejection removes it locally and shows an error. A manager needs a way to investigate the actual work and apply a reasoned correction where appropriate. Do not advertise permanent retention of every rejected local attempt.
Use a practical acceptance test
Test no internet with good GPS, no usable GPS, reconnection, repeated delivery, changed assignment and a terminal rejection. Check both the worker message and server result. Also test the app resuming: automatic retry does not mean an operating system will run a terminated app indefinitely.
The offline feature page summarizes product availability. The correction guide explains the review path when a genuine shift remains incomplete.