Offline app for field teams: synchronisation, conflicts, photos, signatures and ERP

A desktop app breaks when the Wi-Fi drops. A field app lives without a network: a car-park basement, a boiler room, a reinforced-concrete technical room, a rural building site, a lift shaft. If the tool shows a blank screen at those moments, the technician goes back to paper the next day, and your project is dead without anyone announcing it.

Offline mode is therefore not an option for a field business mobile app (in French): it is the feature that conditions all the others. It is also the most underestimated one in requirements documents. This guide sets out what it really involves: architecture, synchronisation, conflicts, photos, signatures, ERP integration and budget.

Why "offline" is an architectural decision

Most apps are built "online first": every screen queries the server, every button sends a request. Adding offline afterwards means rewriting half the app.

A field app is built the other way round, local first:

• A database on the phone (SQLite, or a layer on top such as WatermelonDB, Realm or Drift depending on the technology). The interface reads from and writes to this database only.
• An upload queue: every action (job closed, photo taken, part used) becomes an operation recorded locally, then sent to the server as soon as possible.
• Identifiers generated on the device (UUIDs): a work order created in a basement must have its permanent identifier immediately, without waiting for the server.
• A synchronisation engine that pulls the server's changes down and pushes the queue up, in both directions, in small batches, resuming after a dropout.

The user should see none of this. They work, the app saves, and a discreet indicator tells them what is still waiting to be sent.

Defining what must be available offline

Putting everything on the phone is impossible and pointless. The real scoping question is: what does the technician need without a network, for their day?

Two rules to remember. First, any data shown offline must carry its freshness ("stock as at 22/09, 7:40 am"): a technician who believes a figure is up to date makes bad decisions. Second, synchronisation must be incremental: you only download what has changed since the last pass, otherwise every start-up takes three minutes on weak 4G.

Synchronisation: the heart of the project

Upstream: the operation queue

From phone to server, the most robust model is the operation queue: you do not send "the state of the job", you send "the technician added this part at 10:12", "the technician closed the job at 11:05". Each operation carries a unique identifier, which makes sending idempotent: if the network drops midway and the app resends the same operation, the server recognises it and does not create a duplicate.

This detail avoids the classic problem of badly designed field apps: three identical work orders in the ERP because the technician pressed "send" three times in an area where the network kept coming and going.

Downstream: the sync cursor

From server to phone, each device keeps a cursor ("last sync: timestamp or version number"). When the network returns, it asks for everything that has changed since, including deletions, which are often forgotten: a job cancelled at the office must disappear from the phone, not linger as a ghost in the schedule.

When to synchronise

• When the app launches and when it returns to the foreground.
• When the network returns, detected automatically.
• In the background, within the limits imposed by iOS and Android (which guarantee neither the frequency nor the exact timing).
• On demand, with a "Sync now" button and a visible counter of items waiting.

That last point matters more than it seems: the team leader wants to be able to check, before leaving the site, that zero items remain stuck on a phone.

Conflicts: write the business rule before the code

A conflict occurs when the same data is modified in two places while one of them was offline. A typical example: the office moves a job to the next day while the technician, in a basement, closes it.

The temptation is to apply "last write wins" everywhere. It is simple to code and dangerous: the office's change, arriving second, would silently wipe out the technician's closure.

The right approach is to write down, field by field, who has authority:

This table is a scoping deliverable, validated by the operations managers, not a decision left to the developer. It often fits on one page and saves weeks of disputes after rollout. To structure it in a consultation document, our article on the requirements document for a mobile app gives the skeleton.

Finally, plan a conflicts screen in the back office: the rare cases the rule cannot settle are escalated there, with both versions side by side.

Photos: the real weight of the project

In a field app, photos make up most of the data volume: before/after condition, proof of visit, meter reading, snagging item. A technician can produce several dozen a day. Without processing, a modern smartphone photo weighs several megabytes, and a whole day's worth never uploads on weak 4G.

What to plan for:

• Compression at capture: resize to around 1,600 to 2,000 pixels wide and recompress. For the vast majority of uses (inspection report, proof), the difference is invisible and the weight is divided by five to ten.
• Separate local storage for the files, with the link to the job in the local database.
• Background upload, file by file, with resume: a dropout at 80% of a photo must not send the whole batch back to square one.
• Useful metadata: date, time, job, possibly GPS position if it is justified and accepted by employees (see below).
• Annotation: circling a leak, drawing an arrow at a crack. It is often the feature teams like most, and it works on the local image, without a network.
• Clean-up: delete files from the phone once the server has confirmed receipt, otherwise storage fills up within a few weeks.

One often-forgotten point: the capture mode. If the app sends the user to the phone's gallery, job photos get mixed with the employee's personal photos. A camera built into the app solves the problem and speeds up the gesture.

Customer signature: what to capture

The on-screen signature at the end of the job replaces the paper slip. Technically, drawing it with a finger is trivial. What matters is what surrounds it:

1. The signed document is frozen: the summary (work, parts, time spent, any reservations) is generated, then locked at the moment of signing. Any later change creates a new version.
2. The evidence is attached: timestamp, identity of the logged-in technician, the signatory's typed name, the job identifier, and a fingerprint (hash) of the document.
3. The PDF is generated on the phone, so it can be signed and left with the customer even without a network; the email goes out automatically when the connection returns.
4. The absent-customer case is covered: deferred signature, a reasoned refusal to sign, or a photo of the paper slip as a fallback.

Legally, a simple electronic signature is admissible in France and the European Union (the eIDAS regulation); its evidential weight depends on the quality of the evidence above. For the most binding documents (acceptance report for works, a large quote), we rely on an advanced electronic signature provider, which generally needs a connection at the moment of signing. This is a trade-off to make during scoping, document by document.

ERP integration: never plug the phone in directly

The field app almost always has to talk to an existing system: ERP, maintenance management software, billing tool, construction-industry software. The temptation is to have the phone talk to it directly. This is almost always a mistake.

ERPs were rarely designed to receive hundreds of small requests from intermittently connected phones. They have maintenance windows, slow spells, formats that change with every update, and sometimes a limited or even non-existent API.

A sound architecture inserts an intermediate back end:

• The phone syncs only with this back end, which is designed for offline (idempotency, cursors, conflicts).
• The back end talks to the ERP at its own pace: through an API where one exists, otherwise through scheduled file exchange, with a retry queue.
• If the ERP is down, the field keeps working normally; the data goes up when it comes back.
• Every exchange is logged: when an invoice is missing from the ERP, you know within two minutes where it stopped.

Count the ERP integration as a project in its own right, with time to study the existing system: this is often where the biggest budget uncertainty hides. The same back end generally also serves as the back office for the office team (planning, monitoring, conflicts screen).

Technical choice and points not to neglect

For intensive field use, a native or cross-platform app (React Native, Flutter) is the reasonable choice: large local storage, background tasks, full access to the camera and files. A PWA can be enough for a few light forms, but its storage and background operation remain more limited, especially on iPhone. The detailed comparison is in our article React Native, Flutter or native.

A few points that make the difference in production:

• The devices: rugged or consumer smartphones, a mixed Android fleet, screens readable in full sunlight, buttons usable with gloves. We test on the teams' real phones, not just the latest models.
• Local data security: encryption of the on-device database, remote sign-out of a lost phone, fleet management (MDM) if the company has one.
• Employee geolocation: it must be justified, proportionate and known to the teams; in practice, we often limit ourselves to timestamping the start and end of a job rather than tracking continuously.
• Updates: when the data format changes, phones that have not yet been updated must still be able to sync. The back end must accept at least the previous version of the app.
• Monitoring: knowing how many operations are waiting on each device, and detecting a phone that has not synced for three days.

Realistic budget and schedule

Offline mode is not an isolated line on a quote: it touches the local database, synchronisation, conflicts, testing and the back end. In our experience, it represents roughly 20 to 40% more budget than the same app designed online-only, depending on the number of synchronised objects and the complexity of the conflict rules.

These timelines are indicative; our low prices and the detail of our plans are on the mobile app pricing page. For a first scope, an MVP centred on a single journey (receive the schedule, carry out the job, get a signature, send it back) is often the right starting point, with ERP integration limited to the essential flows.

On the schedule side, set aside two to four weeks of field pilot with a real team before general rollout. That is where unexpected dead zones, phones that are too old and badly thought-out conflict rules show up. And budget for what follows: iOS, Android and the ERP change every year, and an unmaintained field app degrades quickly. Our article on the cost of maintaining a mobile app details this item.

In summary

A successful field app can be recognised by one detail: the technicians no longer think about the network. To get there, you need to design local first, write the conflict rules with the operations people, treat photos as a subject in their own right, surround the signature with evidence and isolate the ERP behind a back end built for intermittent connectivity.

These choices, made at scoping stage, are what separate a tool that is adopted from one abandoned after three weeks. To see how we approach these projects for construction, maintenance and field service companies, see our dedicated page on the field business mobile app (in French).

Do you have an app project for your field teams, or an existing tool that does not hold up without a network? Contact us: a first conversation is enough to scope the offline requirements, the integration with your ERP; the quote follows within 24 hours.

Sources

• Règlement (UE) n° 910/2014 (eIDAS) sur l’identification électronique (in French) — EUR-Lex (European Union)
• Article 1367 (in French) — Légifrance
• Créer une application orientée hors connexion (in French) — Android Developers