Save now; validate when the connection returns
A worker may have a usable camera and location fix at a site with unreliable internet. The personal-device app can preserve the attendance capture locally, including the event time and evidence needed for synchronization. It assigns a unique event identifier so a retry of that event does not create another accepted record.
The phone’s pending status means the capture has not completed synchronization. It does not mean payroll has received approved hours. Server authorization, site and verification checks still apply when the event arrives.
Follow the complete lifecycle
Scroll the table sideways to read all columns.
| State | What the worker or manager can know |
|---|---|
| Captured and queued | The phone holds a local capture and shows a pending count |
| Network retry | The app keeps the queued capture and tries again when it can run and connect |
| Accepted | The server stores attendance; it becomes available to dashboard and timesheet processing |
| Terminally rejected | The app reports the rejection and removes that local capture and selfie |
The dashboard cannot know about a capture that exists only on a disconnected phone. It shows received attendance, not a remote count of every offline queue. Capture time and server receipt time are separate record fields so delayed arrival is distinguishable.
A realistic site example
A worker checks out at 18:00 with no internet. The phone queues the capture. At 18:20, the worker reconnects and opens the app; synchronization can proceed. If validation accepts the event, the recorded checkout time remains 18:00. If the assignment or other checks cause a rejection, the worker needs a supervisor review. The product does not guarantee every saved capture will be accepted.
Attendance rules and assignments can change before synchronization. Test that scenario in the pilot and agree who investigates a missing event. The current server uses the available assignment and effective-policy data during validation; it does not promise a complete snapshot of every capture-time configuration.
Know which surfaces require a connection
Initial setup, replacement-device authorization and shared-kiosk identification require internet. The kiosk flow does not have the personal-device offline queue. App execution also matters: automatic retry is not a promise that an operating system will run a terminated app.
Before rollout, test airplane mode, poor connectivity, reconnection, duplicate retry and a rejected event on the actual devices. Keep a documented route to record genuine work when technology fails.