An open form without a connection is not proof of an offline work order. Hours, materials, notes and attachments must remain identifiable locally and later reach the correct server record without duplicate effects.
Use the English offline-sync worksheet. This is a requirements and test model; it does not establish that an OmniTechs or supplier application already supports offline work.
Decide what each field may do offline
Assign read, edit, add or blocked behaviour per field. A technician might record hours and notes while scheduling or invoicing remains online.
| Component | Required behaviour to test |
|---|---|
| Hours | Saved locally and confirmed as one server entry |
| Material | Item and quantity remain linked to the same order |
| Note | Text and revision time remain visible |
| Photo | Queued file reaches the right order with confirmation |
Define which components are mandatory before the order can advance. A confirmed text entry does not prove its attachment uploaded.
Make local state visible and persistent
Show the affected order, latest local change, pending actions and attachment status. Test closing and reopening the application while offline and, where required, restarting the device. Missing drafts, empty thumbnails or an unexplained reset are failures.
Also interrupt the connection during saving. Expect either one identifiable local draft or a clear failure with no change. Two copies with unknown status leave the user unable to decide what to retry.
Treat retries as the same operation
Define local, sending, confirmed and rejected states for each component. Use a stable operation identifier so a timeout and retry do not create another hours line or attachment.
Provide a visible resume route
Background behaviour depends on the actual platform. Test it and provide an explicit resume route where needed. A spinner does not prove whether the server has zero or one final record.
Define conflicting edits before they happen
Suppose material quantity was two when a technician went offline. The technician changes it to three while office staff change it to four. In this illustrative scenario the required outcome is a visible conflict showing both values and a responsible decision-maker, not silent overwriting.
Other workflows may permit field-by-field merging or a controlled new revision. Choose and test the business rule; retain enough evidence of the conflicting values to understand the decision.
Test the complete recovery chain
A fictional order has hours, material, note and photo. After reconnecting, three are confirmed and the photo remains queued. It is partially synchronised, not ready for the next stage if the photo is mandatory.
A repeated photo upload should lead to one confirmed attachment. A separate material conflict can still keep the order incomplete. These are invented test conditions, not measured app capabilities.
Accept the complete chain rather than one component
Approve the scenario only when mandatory components are confirmed, repeated sends do not duplicate records and conflicts remain visible. Stop when local work disappears or nobody owns the queue.
Explore the digital work-order workflow, work-order app requirements and field-service process. Choose mobile app development based on the required device behaviour and recovery, rather than assuming field work automatically requires one platform.