Offline Field Service: Local Storage Limits and Sync Conflicts

Local Storage is a key-value cache, not a database. It has no relationships, no queries, no transactions, and a modest size ceiling. Serializing the whole work-order list to JSON makes every read and write a full-document operation, which is why errors appear around 8 MB and why reinstall destroys unsynced work. It also cannot express partial sync or conflict detection.

Use offline entities with Offline Data Sync. Model WorkOrder, WorkOrderPhoto, and the reference data the technician needs as entities available offline. Sync only work orders assigned to that technician, and only the asset history needed for the visit; fetch the full 12 months on demand when connectivity returns. Use incremental sync with a LastModified watermark, and trigger sync at login, on reconnect, and through background sync. Queue photo uploads separately, compress images before storage, and store them as files rather than base64 inside JSON.

What not to store: long-lived credentials, full customer PII beyond the visit, other technicians' work orders, and unrestricted history. Wipe offline data on logout and on remote wipe.

Trade-off: Offline Data Sync requires native mobile and MABS builds; it gives you a real local database and conflict hooks, which Local Storage cannot.

Last-write-wins is unacceptable because it is silent. The technician works for hours offline and submits an older state; the server overwrites the supervisor's schedule change with no error, no audit, and no way for either user to know. The data loss is discovered later, usually by the customer.

Add a version or LastModified plus ModifiedBy to the order and send the expected version with the update. The server compares versions inside the same transaction as the write. On mismatch it returns a conflict payload containing the server state, the changed fields, and who changed them; the client shows the technician a merge decision rather than discarding either side.

Assign field ownership to reduce conflicts: supervisor owns schedule and assignment; technician owns work notes, status, and photos. Merge non-overlapping fields automatically, and require human resolution only when the same field changed. Photos are append-only, so they never conflict.

Use server timestamps, not device clocks, and log every conflict outcome for audit. Test with airplane mode, two devices editing one order, and a supervisor changing the record mid-sync. The goal is not zero conflicts; it is zero silent losses.

Treat the 80 MB plugin as a product decision, not a build setting. MABS build and upload time grows with app size and plugin count, and every plugin adds OS permissions and review burden. First confirm whether the scanning capability is actually used; if it is a barcode, a smaller or built-in plugin may do. Remove unused plugins before adding two more, and challenge each new plugin against the requirement rather than the request.

If scanning is occasional, consider invoking it through a web view or a server-side flow and keep the native binary lean. If the plugin is core, accept the build cost but schedule builds, cache dependencies, and avoid adding non-essential plugins to the same app.

PWA trade-off: a Progressive Web App avoids MABS, plugins, and app-store distribution, and can work offline with a service worker and browser storage. But it does not give you OutSystems Offline Data Sync, native camera and scanner performance, or the same device management story, and browser storage eviction is a real risk. For 180 technicians working 6 hours offline with photos, native plus offline sync is defensible; the decision should be driven by the offline and hardware requirements, not by build time alone.