Making Power Apps work offline
Many organizations have employees who work in the field without reliable internet connectivity: technicians at remote locations, inspectors in buildings with poor coverage, or salespeople on the road. For these scenarios, offline functionality in Power Apps is crucial. But what exactly can work offline, and what are the limitations? In this article, we provide an honest overview of the capabilities and share practical strategies.
The difference between canvas and model-driven
The offline capabilities differ significantly between canvas apps and model-driven apps. Canvas apps offer limited but flexible offline support via local collections and the SaveData/LoadData functions. Model-driven apps have a more integrated offline experience via the Dynamics 365 mobile app, but with stricter configuration requirements. The choice depends on your specific use case and the level of offline functionality you need.
Canvas apps: offline capabilities
In canvas apps, you can work offline by storing data locally with the SaveData function and retrieving it with LoadData. When the app starts, you check the connection status with the Connection.Connected property. Is there a connection? Then you fetch fresh data from Dataverse or another source and store it locally. No connection? Then you work with the locally stored data.
Changes users make offline are stored in a local collection that acts as a queue. Once the connection is restored, you loop through this queue and synchronize the changes back to the server. This pattern requires careful implementation because you need to account for conflicts, error handling, and the order of operations.
Model-driven apps and offline
Model-driven apps offer a more out-of-the-box offline experience via the offline profile in the Power Platform admin center. You configure which tables and filters should be available offline, and the Dynamics 365 mobile app automatically synchronizes the right data to the device. This works with Dynamics 365 Field Service and other modules.
The advantages are clear: less customization needed, automatic synchronization, and support for complex data models. But there are also limitations. Not all functionality is available offline: plugins and real-time workflows only run when data is synchronized, custom controls may behave differently, and there are limits on the amount of data you can store offline.
Offline functionality is not an afterthought but an architecture decision. Plan it from the start in your design and test extensively with realistic scenarios in the field.
Synchronization strategy and conflict handling
The biggest technical challenge with offline apps is conflict handling. What happens when two users edit the same record offline? Dataverse uses a last-write-wins strategy for model-driven apps. With canvas apps, you need to implement conflict detection yourself, for example by comparing version numbers or timestamps. Also consider what data actually needs to be offline. The less data you synchronize, the faster the synchronization and the smaller the chance of conflicts.
A proven strategy is to synchronize read data broadly (reference tables, product catalogs) and limit write operations to what is strictly necessary. A technician may need to read all work instructions but only writes service reports and time registrations. This minimizes conflicts and keeps synchronization fast.
Practical tips and limitations
Based on our experience at Breathbase, we share a number of practical tips. Always test on actual devices in the field, not just in the browser. Performance and behavior can differ significantly. Keep the offline dataset small and use filters to synchronize only relevant data. Build a clear visual indicator into your app that shows users whether they are online or offline, and when the last synchronization occurred.
The key limitations to account for are: limited storage space on mobile devices, no support for complex queries offline, no real-time notifications, and potential performance issues with large datasets. For very complex offline scenarios, consider a native app or hybrid solution with Power Platform as a backend. Plan offline functionality from day one in your architecture and you will avoid costly rebuilds later.
