"Can the mobile app work offline?" is one of those questions where the honest answer is longer than clients want to hear. Yes, with real limitations, and those limitations should shape the screens you design for mobile, not be discovered after go-live when a warehouse loses wifi and a picker's completed work vanishes. This is what actually works, what doesn't, and how I scope offline requirements so nobody gets an unpleasant surprise.
What the app caches, and what it deliberately doesn't
Offline support in Acumatica Mobile caches a bounded working set locally on the device: the specific records a user has recently viewed or explicitly downloaded for offline access, plus reference/lookup data needed to render those screens (customer names for a dropdown, inventory descriptions). It is not a full local replica of your instance's data — there is no expectation that a device holds every sales order or every inventory item. Screens and data outside that bounded, recently-touched set simply aren't available offline, and the app needs to make that boundary visible to the user rather than pretend everything works.
What this means practically: offline mode suits workflows where a user has a known, bounded set of records to work through — "these twelve service appointments assigned to me today," "this specific put-away task" — downloaded before going offline. It does not suit "search for any customer and place an order" style workflows, because search against data that isn't cached locally has nothing to search against without connectivity.
Edits queue locally and sync on reconnect — with a real conflict story
While offline, user actions (field edits, new records, action button presses) queue in a local store on the device rather than hitting the server immediately. On reconnect, the app replays the queue against the server's REST/contract API in order. The part that requires actual design attention: what happens when a queued edit conflicts with something that changed on the server in the meantime — another user modified the same record, or a status transition the mobile edit assumed is no longer valid by the time it syncs.
If you've added a custom action reachable from an offline-enabled mobile screen, its server-side graph logic runs exactly as if the user had just clicked it live — the graph has no inherent awareness that the click happened hours earlier while offline. Any RowPersisting validation that depends on "current" state (today's date, another field's live value, a status that could have moved on) needs to explicitly consider whether a stale offline edit should be rejected with a clear error rather than silently applied against now-outdated assumptions. I've seen a custom approval action approve a document offline that had already been cancelled server-side in the interim — the sync replayed the approval anyway, because nothing in the custom logic checked for that.
What genuinely does not work offline, and needs to be scoped out up front
- Live server-side validation against current data. A
PXSelectoror lookup validating against server data can't validate against data the device doesn't have cached — offline entry of a field backed by a live lookup either falls back to whatever was last cached, or is disabled entirely, depending on how the screen is configured. Test this explicitly; don't assume selectors "just work" offline. - Anything requiring a server round trip mid-transaction — a custom action that calls an external API, generates a document number from a live sequence, or needs a real-time credit check. These need to either be disabled while offline or deferred to sync time, and deferring changes the UX (the user doesn't get the actual result until reconnect, only an "queued" acknowledgment).
- Large attachments queued offline — photos and documents captured offline (see photo attachment capture) queue locally too, and sync bandwidth for several megabytes of photos over a spotty reconnect is a real, not theoretical, constraint on slow rural or warehouse connectivity.
The scoping conversation I have on every offline request
Before building anything, I walk the client through three concrete questions, because the answers change the screen design entirely: What is the actual connectivity gap — total dead zones with no signal for hours, or just spotty/slow connections? (These need different solutions; spotty connections are often better solved with aggressive retry and smaller payloads than with a full offline queue.) What is the maximum acceptable staleness for reference data the offline screens depend on — is a customer list from this morning fine, or does pricing need to be genuinely current? And what should happen to a queued edit that conflicts on sync — silently apply, silently drop, or surface for a supervisor to resolve? Getting these three answers before designing the mobile screens avoids the worst outcome: a warehouse team that stops trusting the app because a shift's worth of scanned data silently failed to sync one time, and nobody can explain why.
Test with airplane mode, not just a slow connection
A slow connection and no connection exercise genuinely different code paths — a slow connection still gets synchronous responses eventually, while true offline forces the local queue and replay logic to actually run. Every offline-enabled screen I ship gets tested with the device in airplane mode for a realistic session (multiple record edits, at least one custom action invocation, at least one deliberately-conflicting edit against a record changed server-side in the meantime) before I call it production ready. Skipping this and only testing on a slow office wifi network is how offline bugs make it to a client's actual warehouse.
Wrapping up
Acumatica Mobile's offline mode is a bounded local cache plus a queue-and-replay sync, not a full offline database — and treating it like the latter is where implementations go wrong. Scope which screens genuinely need offline support based on a bounded, known working set, design custom validation and actions to handle stale-on-sync conditions explicitly, and test in real airplane mode with realistic conflict scenarios before trusting it in front of a client's field team.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.