Canvas app offline mode

Field workers, warehouse staff, on-site technicians, sales reps in flaky connectivity — for any user who works without reliable network, an app that fails offline is an app that fails. Power Apps canvas apps support offline mode with local data, scheduled sync, and conflict handling. The architecture is functional; the design patterns to use it well matter.

The model. An offline-capable canvas app:

• Pre-loads data from Dataverse (or other connectors) into a local SQLite database on the device.
• Uses the local data for reads and writes while offline.
• Synchronises to the source when connectivity returns.
• Handles conflicts when remote data has changed since the local copy.

Configuration.

In the app designer:

• Enable offline — the app's Offline setting in settings.
• Define offline tables — which Dataverse tables (and filtered subsets) the app caches locally. Configured as collections with explicit LoadData() / SaveData() patterns, or via the newer Profile declarative offline support that handles caching automatically.
• Sync schedule — frequency of background sync when online (typically every 5–15 minutes).
• Manual refresh — a button users can click to force sync.

Data scope. Offline mode is most useful when each user works with a subset of data:

• A field technician needs only today's work orders and the related customer / asset records.
• A warehouse picker needs only items in their assigned zones.
• A sales rep needs only their accounts and recent opportunities.

Pre-loading 10,000 records per user is feasible; pre-loading 100,000 is impractical (storage, performance). Define offline profiles narrowly to keep the local dataset focused.

Read patterns offline.

• Standard Filter(), Search(), LookUp() functions work on the local cache transparently.
• Performance is typically faster offline than online (no network round-trip).
• Related-record lookups need the related records in the offline cache too — pre-load related tables.

Write patterns offline.

• Writes happen to the local store; sync queues the changes for upload.
• The user sees their write reflected immediately in the local UI.
• On reconnect, queued changes flush to the source.
• The UI typically shows a sync status badge — "online", "syncing", "offline with N changes pending".

Conflict handling.

When the user writes offline and someone else has modified the same record online:

• Last-writer-wins (default) — the local write overwrites the remote on sync, potentially losing the remote change.
• Server-wins — the local change is discarded if remote has changed.
• Manual conflict resolution — surface the conflict to the user; let them choose. Most reliable but disruptive.
• Field-level merge — for non-conflicting field changes on the same record, merge cleanly; only true conflicts surface.

The app's design chooses the strategy. For most field-service scenarios, last-writer-wins on the technician's update is acceptable; for sensitive records, manual resolution is safer.

Photos and attachments. Photos taken offline cache locally and upload on reconnect. The app handles the queue; the user just takes the photo and trusts the platform.

Limits.

• Storage caps — each app's offline cache has limits (typically a few hundred MB depending on device).
• Not all connectors support offline — Dataverse is well-supported; SharePoint and SQL have varying degrees; others may not work offline.
• No real-time during sync — sync gaps mean the local data is stale by definition.
• Complex relationships can be hard to fully cache — deep many-to-many networks don't always pre-load completely.

Common patterns.

• Pre-load on app launch — app opens, syncs immediately, ready for the day's work.
• Pre-load on schedule — daily morning sync before users start.
• Manual sync action — a button for explicit sync; users learn when they need it.
• Status indicators — visible sync status, pending changes count, last sync timestamp.

Common pitfalls.

• Pre-loading too much — users wait minutes for sync; performance degrades.
• Not handling conflicts — last-writer-wins by default loses remote work users care about.
• No retry on sync failure — temporary network issues leave changes stuck. Implement retry with exponential backoff.
• Stale data assumed fresh — users act on data that's 4 hours old, not realising. Show sync timestamp prominently.

Operational discipline.

• Test offline scenarios deliberately — fly mode, weak signal, intermittent connectivity. Don't just test online with airplane mode briefly.
• Train users on the offline indicators and behaviour.
• Monitor sync failures in telemetry; investigate patterns.
• Pilot with field users before broad rollout.

Done well, offline canvas apps transform the productivity of field workers; done badly, they erode trust in mobile work.