A technician finishes a visit in a basement with no reliable connection. The app shows a success message, so they close it. Later the office cannot find the notes. Another version of the same failure is worse: the notes arrive, but an old copy of the job also overwrites the dispatcher's new assignment.
Offline support needs more than caching the page. It needs a clear agreement about which actions can be recorded locally, which require the server and what the user is told when the two disagree. Design that agreement around the work a technician must complete without signal.
Make the save state understandable
Use separate states for an unsaved edit, a durable local save, an upload in progress and server acceptance. A single green check cannot explain all four. The technician should know whether the office can see the information and whether it is safe to leave the screen.
Do not present local storage as an unlimited guarantee. Device settings, storage limits and browser behaviour can affect persistence. Test the supported devices and provide a visible warning when a local write fails. If the application cannot retain the edit, keep it on screen and explain the problem rather than pretending that synchronisation will fix it later.
Show a pending work list that is reachable without opening every job. It should identify unsynced notes, photos and actions separately, because one large attachment can remain pending after the text has arrived successfully.
Queue the action, not a complete old record
An offline update should describe what the technician did: added an observation, recorded a part used or proposed a completion status. Include a stable operation identifier and the record version on which the action was based.
Sending the entire downloaded job back as its replacement risks restoring stale office fields. The technician may be allowed to add findings but not change the billing contact or a reassignment made while the device was offline. Field level ownership and action specific server validation prevent that accidental overwrite.
Keep local operation identifiers stable across retries. Reopening the app or tapping sync again must not create another copy of the same note. The server should be able to report that an operation was already accepted and return the resulting record reference.
Not every conflict should be merged automatically
Two appended observations can often coexist. Two different completion times or two conflicting equipment identifiers need a rule. An assignment change may make a later action unauthorised even though the technician was authorised when they downloaded the job.
Preserve the submitted information when rejecting an action. The office may still need a technician's observation after a reassignment, even if the technician can no longer mark the job complete. Route the information to review with its original context instead of discarding it as a generic sync error.
Present conflicts in operator language. Explain that the office changed the appointment after this device last synced, and show the fields that need review. A raw version mismatch code tells staff nothing about whether their work was lost or what they should do next.
Photos require their own recovery path
Treat an attachment upload separately from its association with a visit. A connection can fail after the file reaches storage but before the application records that association. Use a stable upload reference and a completion check so a retry can recover the existing upload instead of leaving orphan files or attaching duplicates.
Limit file sizes and explain progress without blocking all text work behind one upload. Where image compression is used, verify that the resulting image still contains the information required for the job. A smaller identification plate photo is not useful if its text becomes unreadable.
Provide a way to retry or remove a failed attachment while keeping its associated note. The technician should not have to recreate the whole visit because one photograph failed.
Authentication still matters offline
Decide which downloaded data may remain available when a session expires and what sign out should remove. Shared devices need particular care: the next person must not inherit another technician's customer records through an offline cache.
Server acceptance always needs current authorisation. A locally queued operation is evidence of intended work, not a permanent permission grant. If access has been revoked, retain only what the approved recovery policy allows and route any necessary recovery through an authorised process.
Avoid downloading the entire customer database for convenience. Scope the offline package to assigned work and the history required to perform it. Record its freshness and remove information that is no longer needed under the application's retention rules.
Test a broken connection as a sequence
Start with a downloaded job, disable connectivity and add a note. Close and reopen the application, then confirm the note and its local status remain visible. Change the job from the office while the technician is offline, reconnect and inspect both the server record and the technician's conflict message.
Repeat with an attachment partly uploaded, an expired session and the same operation retried twice. Test storage failure rather than only network failure. A workflow can handle a lost connection correctly while still losing data when the device cannot save locally.
Finally ask a technician and an office operator to explain what the status indicators mean. They should agree about what is saved, what is visible to the office and what requires attention. Offline support succeeds when it preserves useful work and makes uncertainty visible, not when the interface merely remains open without a network.