A technician finishes a site visit in a basement with no reliable connection. They need to record the work, attach photographs and move to the next job. If the app simply displays a loading spinner, the team may fall back to paper and retype everything later. Offline support should begin with that working situation, rather than a promise that the whole product will work without internet.
For Irish field-service and delivery teams, a useful first release can support a small set of offline tasks reliably. This guide covers local drafts, reconnection and conflicting updates. For the broader platform decision, see our web app versus mobile app comparison.
Define what staff can do without a connection
List the tasks a person must finish during a visit. These might include reading an assigned job, recording measurements, adding notes and preparing a completion report. Separate those from actions needing a fresh server decision, such as assigning a new job or confirming a live stock reservation.
Be explicit about limitations. A locally saved report is not yet a submitted report. A downloaded address may have changed since the device last connected. Show the last successful update time near information where freshness matters. Agree how staff contact the office when a blocked action is urgent.
Download the minimum useful working set
Prepare the day's assigned jobs while the device is connected. Include only the records and reference information needed for the work. Avoid copying an entire customer database to every device simply because local storage is available. Design a retention rule for completed jobs and a clear separation between users on shared devices.
Ask field staff to try the preparation step on their actual phones. A large photograph library may work on an office connection but fail during the morning journey. Decide what should happen when only part of the working set downloads, and make missing information visible before someone arrives on site.
Make saved and submitted different states
Use understandable status labels such as saved on this device, waiting to send, submitted and needs attention. Confirm the local save before staff leave the screen. Do not display a server confirmation until the server has accepted the change and returned a durable reference.
Keep a visible queue of pending items with a manual retry action. MDN documents the Background Synchronization API, which can defer work until connectivity is available, but browser support is limited. Treat background sync as an enhancement and provide a foreground recovery path for the devices you support.
Decide how conflicting changes are resolved
Imagine the office cancels a job while a technician completes it offline. Automatically keeping whichever update arrives last may erase useful work or reopen a cancelled visit. Agree the business rule before implementing the sync mechanism. Preserve the submitted notes while asking an authorised person to resolve the job status where appropriate.
Use record versions or another explicit conflict check so the server can recognise that an update was based on older information. Show a helpful explanation when action is required. For ordinary notes, adding a new entry may be safer than replacing a shared paragraph that several people can edit.
Prevent duplicates during reconnection
A connection can fail after the server saves an update but before the phone receives its response. The next attempt must be safe. Give each intended operation a stable identifier so the server can recognise a repeated submission rather than create another completion report, stock movement or invoice instruction.
Keep attachments linked to the correct job and operation throughout retries. Display progress per attachment where useful. A report should not appear fully submitted while required photographs are still waiting on the device. Our inventory synchronisation guide explores similar ownership and reconciliation decisions for connected stock systems.
Plan for lost devices and expired sessions
Offline access introduces a practical trade-off: information already downloaded may remain available while a device cannot contact the server. Define what can be cached, how long it is retained and what happens after logout or a user change. Review those decisions with the people responsible for the information.
Do not assume remote account removal instantly erases an offline device. Define the local access policy, device-management expectations and reconnection checks. A customer portal and a staff field app may need different data boundaries even when they share the same backend.
Test a real working day
Run through a visit in airplane mode, restore the connection halfway through an upload and repeat a submission. Close and reopen the app with work pending. Test an expired session, low storage, a changed assignment and a shared-device handover. Use test records rather than live customer information.
Pilot with a small team and measure lost drafts, duplicate submissions, sync failures and time spent retyping notes. These are more useful acceptance criteria than a generic offline badge. Elephantfly plans and builds mobile apps for Irish businesses. Bring us a field workflow and the devices your team uses to define a realistic offline scope.
Further exploration
Sources & references
- 01
