# A field report can be saved without reaching the office

Design offline work around a durable draft, an identifiable submission and a server receipt. Each answers a different question for the person holding the phone.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Start with the promise on the button

Imagine a technician completing an inspection in a basement. They add three photographs, record a damaged valve and tap Save. The phone has no connection. If the screen says Submitted, the office may expect a report that exists on only one device.

Use separate states such as Saved on this device, Waiting to send and Received by the office. Show the last confirmed receipt time beside the job. A connectivity indicator cannot tell the user whether a particular report reached the server.

This distinction also shapes the data model. A draft can change freely. A submission is an identified business command whose outcome must remain explainable across retries. The server receipt confirms that command, not merely that an HTTP connection opened.

## Keep the report and its pending command together

IndexedDB provides transactional browser storage for structured records and files. A practical design stores the draft and its queued submission in one local transaction. Otherwise a crash between the two writes can leave a report looking ready with no instruction to send it.

Give the submission a stable identifier before the first network attempt. The server associates that identifier with the result, so a lost response can be recovered without creating another report. Scope the identifier to the relevant organisation and authenticated workflow.

### From local draft to confirmed report

The screen advances only when evidence for the next state exists. An interrupted transfer resumes against the same submission identity.

1. **Local transaction**: Save report, attachment references and queued command
2. **Transfer attempt**: Upload missing files and submit the stable command
3. **Server decision**: Check authority, version and duplicate identity
4. **Receipt on device**: Persist the accepted result before clearing pending work

## Resolve a changed job without erasing either version

Suppose the office changes the inspection instructions while the technician is offline. Sending the whole old job object back could overwrite that change. Include the version the technician started from and distinguish their observations from office-owned fields.

Some differences can merge safely, such as adding a new observation with its own identity. A conflicting completion status may need a person to choose. Present the changed fields and the consequence of each choice. A generic Retry button cannot resolve a business disagreement.

Keep attachments associated with the submission throughout this process. An uploaded photograph without an accepted report should remain recoverable or become eligible for deliberate cleanup. It should not silently count as a completed inspection.

## Treat installation as convenience, not a delivery guarantee

A PWA can provide an installed entry point and an offline application shell. That does not guarantee unlimited storage or unattended synchronisation. Browser storage policies differ, and Background Synchronization is not available in every major browser.

Provide a foreground sync path and a clear way to inspect pending work. Ask for persistent storage where appropriate, handle refusal and write failures, and explain when the user must keep the app open. Never make clearing browser data the first support step for a device holding unsent reports.

If the business cannot tolerate losing the only copy after device loss, define an operational fallback such as earlier check-in points or a different managed-device solution. The architectural decision concerns the acceptable period of unreplicated work, not just whether the application opens offline.

## Sources

- [MDN: IndexedDB](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API)
- [MDN: browser storage quotas and eviction](https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria)
- [MDN: Background Synchronization](https://developer.mozilla.org/en-US/docs/Web/API/Background_Synchronization_API)