Offline and Permissions
Unlike the progressive web app, the native app can work genuinely disconnected.
Where to find it
Architect Panel → Mobile Apps:
- Mobile Canvas — the app, its screens and its settings
- App Builds & Releases — building and submitting
- Mobile Devices — the devices that have installed it
Architect Panel → Configuration:
- Site Settings — the Mobile Apps option group
Offline mode
The app has an offline mode and a window in days. Screens are individually marked for offline caching, so you choose what is available when there is no signal rather than trying to cache everything.
Cache the screens people need in the field
Today’s work, the job detail, the form they complete. Not the reports, not the history, not the search.
Being selective keeps the cached data small, which matters on a phone, and keeps sensitive data off devices unnecessarily.
Queued changes and the retry window
Changes made offline are queued and sent when a connection returns, within a configured retry window measured in days. Beyond that window, an unsent change is stale enough that sending it is probably wrong.
Duplicates are prevented explicitly
Each queued operation carries an idempotency key. If the same key arrives again, the stored response is replayed rather than the operation being performed twice — and a key reused for a genuinely different request is refused with an explicit error.
This is what stops a flaky connection producing three copies of the same job completion, which is the characteristic failure of offline apps that do not do this.
Tell users what is queued
Somebody working offline needs to know their work is held and not yet sent. An app that looks identical online and offline produces users who close it believing work is saved.
Screen permissions
Each screen can require a permission or name the groups that may see it. Screens the user cannot reach are not delivered to their app at all, rather than shown and refused.
That is the right behaviour — it keeps the app small and it does not advertise what somebody cannot have.
Offline data is data on a device
A phone that is lost has cached records on it. Consider what is cached, keep the window short, require biometric unlock, and be able to revoke a device.
"How long is customer data held on an engineer’s phone" is a question you should be able to answer with a number.
Test offline properly
Flight mode, complete a real task, close the app, reopen it, restore the connection, and confirm exactly one record arrived. That last check is the one people skip and the one that matters.
Worked example
A field app caches today’s jobs and their forms for three days, queues completions with idempotency keys, and shows a banner listing unsent items. Testing in flight mode with a forced app restart confirmed one record arrived, not two.
Recommendations
- Cache only field screens, not the whole app.
- Keep the offline window short — it is data on a phone.
- Show users what is queued.
- Test that exactly one record arrives after reconnecting.