An offline Power App needs more than a cached copy of a list. It needs a deliberate answer to four questions: what is stored on the device, which changes are queued, what happens when two people edit the same record, and how a failed sync can be recovered.
Microsoft provides two different offline routes. Dataverse-based canvas apps can use the platform's built-in offline-first capability. Apps using SharePoint or another connector can use collections with SaveData and LoadData, but the maker owns the sync and conflict logic. These are not equivalent approaches. Microsoft's offline guidance makes that distinction explicit.
Check the boundary before you build
Offline canvas apps run through the native Power Apps Mobile players on iOS, Android and Windows. A canvas app running in a web browser cannot run offline, even on a mobile browser.
For apps embedded in Teams, Microsoft documents a 1 MB limit for data stored through SaveData and LoadData. Images and other media are a poor fit for that limit. The Power Fx function reference also warns that these functions do not encrypt data. Do not cache secrets or data that the device user should not retain locally.
Before writing formulas, confirm:
- The target devices and Power Apps Mobile versions.
- The user's connector permissions while online.
- The minimum records and columns needed offline.
- Whether the information is suitable for storage on a managed device.
- The conflict rule for updates and deletes.
Prefer Dataverse offline-first when Dataverse is the source
For a Dataverse app, enable the built-in mobile offline capability and define an offline profile that limits which tables, columns and related records are downloaded. This route handles download and upload through the platform, but it still needs device testing, security-role testing and a recovery plan.
Do not bolt a second SaveData sync system onto a Dataverse app without a specific reason. Microsoft directs Dataverse-based canvas apps to the built-in offline-first feature.
The collection pattern for other connectors
For SharePoint and other connectors, keep server data separate from pending local changes. A simple design uses:
colCachefor the last downloaded working setcolPendingfor creates, updates and deletes awaiting upload- a client-generated operation ID for retry safety
- a status such as
Pending,SyncingorFailed
Load the device cache without failing the app when it does not exist:
LoadData(colCache, "work-cache", true);
LoadData(colPending, "pending-changes", true)
When a user edits a record, update the working collection and add an operation to colPending. Save both collections after the local change:
SaveData(colCache, "work-cache");
SaveData(colPending, "pending-changes")
Connection.Connected can tell the app that a network is available. It does not prove that SharePoint, Dataverse or a custom API is reachable. Wrap the real connector call in IfError, retain failed operations, and show the user what still needs attention.
Sync deliberately
Process pending operations one at a time or in controlled batches. Record success only after the data source accepts the operation. Never clear the whole queue merely because the device reports a connection.
For edits, store the server record ID and a version value if the data source exposes one. Without a version check, a reconnecting device can overwrite somebody else's newer edit. Decide whether your app will reject the update, keep the server version, keep the device version, or ask a person to resolve it.
Deletes need the same discipline. Mark them as pending locally, upload them when online, and remove them from both collections only after the server confirms the deletion. Account for a record that another user has already removed.
Delegation still matters
The initial online query determines what reaches the device. If it is nondelegable, Power Apps processes only a limited local subset and the offline cache may quietly omit valid records. Check every Filter, Sort and search expression for delegation warnings against the chosen connector. Microsoft's delegation overview explains why increasing the app's row limit is not a reliable fix.
Test failure, not only success
Test on the real mobile platforms with data that resembles production shape, but not production secrets. Cover:
- first launch with no cache
- launch offline after a successful online session
- a connection dropping during an upload
- duplicate retries
- conflicting edits
- a remotely deleted record
- expired authentication after reconnection
- a full or managed device that refuses local storage
Use Power Apps Monitor during connected tests to inspect connector requests and errors. Monitor evidence from a test device does not prove every network, device policy or production data shape will behave the same way.
For more practical patterns with the security and recovery boundaries left intact, join the Power Apps Builders Space.