Working offline — recording production when the Wi-Fi drops
The works-order page keeps working without a network: clock-ins, clock-outs and step updates are kept on the device with the time they were pressed and sent, in order and once, when the server is back.
Section 01
What working offline covers
1 minute
Factories lose Wi-Fi for boring reasons: a steel-framed bay, a tablet roaming between access points, a router reboot. The moment it happens the operator is mid-step with a button to press. If the app needs the server for every press, the record is either lost or typed in later from memory — and every time-stamped thing built on top of it (labour hours, the live board, the customer's progress link, the audit trail) is quietly wrong.
So the works-order detail page keeps working without a network, and the three things an operator records there are kept on the device until the server can take them:
- Clock in and Clock out on a step
- Save on a step — status, actual hours, started / completed times, good and scrap quantities
Nothing else is offline. Picking, receiving, stock moves, inspections and creating orders still need the server — deliberately, see Limits.
Section 02
What happens while the network is down
2 minutes
| You do | You see |
|---|---|
| Open a works order you have looked at before | The page opens from the copy kept on the device, with a yellow line at the top: Offline — showing this works order as last seen at 14:02. Orders you have never opened on this device cannot be shown. |
| Press Clock in / Clock out / Save | The row changes at once, a Pending sync chip appears under its status, and the message says Saved on this device — will sync when the server is back. The moment you pressed the button is recorded with it. |
| Look at the top bar | Offline — 3 actions waiting Click it to see the queue: each action, the step, and the time it was pressed. |
| Close the tab or restart the tablet | Nothing is lost. The queue lives in the browser's storage, not in memory, and picks up where it left off when the page is next opened. |
Some shop-floor systems queue offline actions but stamp them with the time they finally reach the server, so a clock-in pressed at 09:12 is recorded at 09:52 when the Wi-Fi returns — and their own documentation warns that an auditor will reject such records as not contemporaneous. Brytebuild sends the time the button was pressed and the server uses that: the time log, the step's start time and the audit entry all say 09:12. The audit entry also records when it arrived, so the gap is visible rather than hidden.
Section 03
When the network comes back
1 minute
The queue is sent on its own — when the browser reports the connection is back, when the page is opened or brought to the front, and otherwise on a retry timer that backs off from two seconds to a minute. You can also press Sync now in the tray. The pill shows Syncing 3… and disappears when the queue is empty; the Pending sync chips go with it and the rows refresh with the server's answer (actual hours from the clock, for instance).
- One at a time, in the order pressed — with a short pause between sends, so a backlog never floods the server.
- Never twice. Every action carries its own id. If a send succeeded but the reply was lost, the retry is recognised and changes nothing.
- No limit and no silent loss. There is no cap on the queue and nothing is dropped without a person choosing to drop it.
Section 04
When the server says no
2 minutes
While a tablet was offline the world moved on. Someone else may have clocked the same step out from another device, or the step may already be complete. When a queued action is replayed and the server rejects it, that is not a network problem to retry — it is a decision for a person.
| What you see | What it means |
|---|---|
| 1 needs attention | At least one queued action was rejected. Open the tray. |
| Rejected | The action, when it was pressed, and the server's reason in its own words — e.g. Already clocked in to this operation. — with Retry and Discard. |
| Held | A later action on the same step, waiting behind the rejected one. It was made assuming the rejected action had taken effect, so it is not sent until you decide. Actions on other steps carry on regardless. |
| Needs attention (chip on the row) | The same thing, seen from the works order — so the person at the machine notices, not only whoever looks at the top bar. |
Retry when the reason was temporary — a step someone has since reopened, say. Discard when the action is genuinely wrong now — the duplicate clock-in, the scrap count already entered by a colleague. Discarding releases anything held behind it, which then sends on the next pass. Both are visible choices; the queue never resolves a rejection on its own.
Section 05
Limits, and why they are limits
1 minute
- Only the works-order page and its recording actions. Offline picking, receiving and stock moves would have to be reconciled against a warehouse that kept moving while the device was away; that is where offline warehouse projects fail, so it is not attempted. Inspections stay live because a gauge's calibration status must be checked at the moment of the reading.
- Only what this device has seen. The page keeps the last copy of works orders opened on it, for up to seven days. A works order never opened here cannot be shown offline.
- The device clock is trusted within limits. A pressed time more than five minutes in the future, or more than seven days in the past, is refused and shows as Rejected with that reason — check the tablet's clock. A clock-out cannot be before its clock-in.
- Logging out clears the copies. On a shared tablet the next person does not inherit the last user's pages.
- The Shop Floor board is live only. It shows what the server knows; work recorded offline appears on it once the queue has synced, with the times it really happened.
A replayed action is booked at the time the button was really pressed. If that time falls on or before the company's accounting period lock (a month the accountant has closed), the server refuses it and the action is parked with the reason, exactly like any other rejection — retry after an admin has moved the lock, or discard it. See Accounting period lock.
Until the pill disappears, the server has not got it. Before a device is wiped, reassigned or its browser data cleared, open the tray and make sure the queue is empty — or the entries on it go with it.