Almost every maintenance app claims to work offline. Almost none of them tell you which actions survive a lost connection, which ones need the network, or what happens to the work you did while it was gone. Those three answers are the whole subject.
Offline is a per-action property
A connection is not present or absent; it is present for some actions and not others. Filing a defect report written on a device in a basement is useful. A stock issue that cannot see the current balance is not — it might take a bin below zero, and the plant's answer would be wrong by the time you read it.
So the honest design is a list, not a slogan: these actions queue, those actions need the network, and the screen tells you which is which before you start typing.
Queued work must be safe to repeat
Shop-floor networks fail mid-request. If a retry can create a second work order, or take the same job twice, nobody will trust the queue. Every queued change carries an identity that makes sending it twice equivalent to sending it once.
A refusal must be visible
The failure mode that kills offline systems is the silent one: a report that appears filed on the device and never reached the plant. A durable refusal is the answer — the report is marked as needing review, with the reason, and retrying returns the same answer rather than looping.
Offline results must say what they searched
When a search box answers with no connection, it can only answer from what the device itself holds. Presenting that subset as the plant's answer is a lie of omission that somebody will act on. Saying “offline results — the plant's machines, jobs and parts are not cached on this device” costs one line of screen space and prevents a wrong decision.
And cold start is its own problem
Capturing work offline is one thing; loading the application with no network at all is another. Ours does not do the second yet, and it is listed as an open item rather than smoothed over.