Custom software and support
An offline inspection form needs two receipts: saved and accepted
A saved message on a disconnected device can be mistaken for confirmation that the office received an inspection. Give local storage and server acceptance different visible states, and preserve a recovery path when synchronization cannot finish.
Answer the inspector’s real question
For facilities teams working in basements or remote buildings, an offline form is useful only if the inspector can tell what will happen to the work. The central design decision is to separate saved on this device from accepted by the shared system. Those are two different receipts with different consequences.
In this illustrative scenario, a technician records a meter reading and a photograph while disconnected. A green check mark appears. The supervisor later sees no inspection and sends someone back. The form may have saved correctly on the device, but its message implied more than the system had confirmed.
A background retry is a convenience, not a receipt
MDN describes the Background Synchronization API as a way to defer service-worker work until a stable network connection is available. It also marks the feature as having limited browser availability and requiring a secure context in supporting browsers. That means an offline web application should not rely on this one capability as its only route to submission.
The proposed interface should offer a visible pending queue and a foreground retry when the worker reopens the app. Browser compatibility must be tested on the devices the team actually uses. Avoid promising that every closed browser will upload every pending form at a fixed time.
Make the state model visible
Use plain labels: saved on this device, waiting to send, sending, accepted by server, or needs attention. Show the last attempt time and a useful reason when submission fails. Keep the local receipt tied to the inspection identifier and version; show the server receipt only after the server validates and accepts that version.
Attachments need the same discipline. If a reading arrives but its required photograph does not, the whole inspection should not look complete. A proposed acceptance rule can require all mandatory parts before completion, while allowing a reviewer to see the incomplete submission with its missing evidence clearly identified.
Resolve changes without silently losing either version
Suppose the office corrects an equipment identifier while the technician is offline. Replaying the old form should not silently overwrite the correction. Compare the version that the device edited with the current server version. Where fields conflict, retain both values and route the difference to an authorized reviewer. This is a proposed conflict policy; its rules depend on the business record.
Give support a safe diagnostic view of the submission identifier, pending state and last error. Staff should not have to ask for an entire device export simply to determine whether a form was accepted. Local storage can also be cleared or lost, so explain its limits and decide what work can safely be collected offline.
Rehearse the difficult journey
Test an inspection across loss of connectivity, app restart, expired sign-in, partial attachment upload and a concurrent office edit. Confirm that retry does not create another inspection, that unresolved conflicts remain visible, and that a server rejection never becomes a success message. Reconcile local accepted receipts against server records before ending the trial.
Editorial hypothesis: a two-lane device/server illustration makes the difference between local save and central acceptance easier to explain to frontline staff. The variable is the two-receipt visual treatment. Comprehension, resubmissions and support demand remain unmeasured. No delivery or reliability guarantee is implied.