What happens to a field form when the connection drops?

A mobile form can look finished in a demonstration and still fail a team working between locations. The important question is what survives when the connection disappears after the user has spent ten minutes entering information.

Distinguish saving from sending

A draft saved on a device and a submission accepted by the server are different events. The interface should say which has happened. A user who sees a vague success message may leave the site believing a colleague can already act on the record.

Use a realistic interruption

For a Colombian field-service team, test a checklist with several photographs. Interrupt the connection during the upload, close the application and reopen it. Check whether the text survives, which photographs remain outstanding and whether retrying creates a duplicate job. Use a synthetic record rather than customer material.

Decide how conflicts work

If office staff edit the same job while a device is offline, the application needs an explicit rule. It might preserve both changes for review or restrict editing after submission. Quietly overwriting one person's work is rarely a satisfactory default.

Offline behavior adds storage, synchronization and security decisions. It should be scoped deliberately rather than assumed from the word app. The IndexedDB documentation describes one browser storage capability; using it alone does not establish a complete offline system. Bring the task and interruption cases to a mobile project discussion.