A requirement that sounds small and is not: "the app needs to work offline." It comes up on most field-work projects, the technicians in basements, the inspectors in rural areas, the warehouse staff in dead zones, and teams tend to treat it as a feature flag, something you switch on near the end. Offline is not a flag. It is an architecture decision that touches what data lives on the device, what the app can actually do without a connection, and the genuinely hard problem of reconciling changes when the connection comes back. Treat it as a toggle and you ship an app that looks offline-capable and corrupts data the first time two people edit the same record in a tunnel.
The reason offline deserves architect-level attention is that it changes the shape of the app, not just a setting on it. An online app can assume the server is always there as the single source of truth; an offline app cannot, and everything from the data it holds to how it handles a conflict follows from that. So the first thing to do with an offline requirement is not to enable offline mode, it is to design the offline behaviour, deliberately, around three questions.
What data lives on the device
The first decision is scope: what subset of data is available offline. The instinct is to make everything available, and that instinct runs straight into a hard limit, because the amount of data you can cache on a device is bounded, and trying to take an entire dataset offline does not work for any non-trivial app. So offline is inherently selective, and the architecture has to decide which data the field user genuinely needs without a connection.
That is usually a far smaller set than the full app: the records assigned to this user, for this route, for today, rather than the whole table. Scoping the offline data to what the user actually needs in the field keeps it within device limits and keeps sync fast, and getting that scope right is most of the offline design. A common failure is not scoping it, hitting the data limit, and discovering late that the offline strategy has to be redesigned around a subset it should have been built around from the start.
How conflicts resolve when the connection returns
The hard part of offline, the part that separates a working offline app from a data-corrupting one, is what happens on sync. While the device was offline, the user made changes locally, and meanwhile the server may have changed too, edited by someone else, or simply moved on. When connectivity returns and the local changes sync up, something has to decide whose version is correct, and that something has to be designed.
If two field users both edited the same record offline, or a user edited a record that changed on the server while they were out, you have a conflict, and the resolution rule is an architecture decision with real business consequences. Does the last write win, does the server version win, does the user get prompted, does the app merge field by field? There is no universally right answer; it depends on the data and the business, which is exactly why it has to be decided deliberately rather than left to whatever the default does. An offline app without a thought-through conflict-resolution strategy is one bad sync away from silently overwriting good data, and because it happens at sync time, away from the user, it is the kind of error nobody notices until the records are already wrong. Designing the conflict rule, and designing it for the specific data, is the heart of an offline strategy.
What the app can honestly do without a connection
The third decision is capability: not every feature works offline, so the design has to be honest about what the app can and cannot do when disconnected. Anything that depends on a live server call, a real-time lookup, an integration, a server-side calculation, a fresh fetch, is not available offline by definition, and the app has to either provide an offline-appropriate alternative or clearly not offer that function until the connection returns.
The mistake is presenting an app as fully functional offline when parts of it silently do nothing without a connection, which is worse than a clear limitation because the user trusts an action that did not happen. So the offline design has to map each feature to whether it works offline, works in a degraded form, or is unavailable offline, and make that honest in the app's behaviour. An offline app that tells the user clearly what it can do disconnected is trustworthy; one that pretends everything works and quietly fails is not.
Confirm offline is actually required first
Before any of this design work, there is a prior question worth asking, because offline is expensive enough to design properly that it should be a real requirement, not a reflexive one: does this app genuinely need to work offline, or does it need to work on intermittent connectivity. Those are different. Genuine offline, no connection for stretches of real work, justifies the full design cost of caching, conflict resolution, and capability mapping. Intermittent connectivity, where the connection drops and returns, can often be served by a responsive online app that handles brief drops gracefully, which is far cheaper than true offline.
The distinction matters because building full offline support for an app that only ever has flaky connectivity is over-engineering, and assuming responsive-online is enough for an app that truly works in dead zones is under-building. The architect's job is to pin down which one the field reality actually requires, and design to that, rather than treating "works offline" as a checkbox that means the same thing in every case.
Designing offline, not enabling it
An offline-capable Power Apps solution is the product of three deliberate decisions, not one setting: a scoped subset of data that fits the device and the user's real needs, a conflict-resolution rule designed for the specific data and business, and an honest mapping of which features work, degrade, or are unavailable without a connection, all of it justified by a confirmed need for genuine offline rather than mere resilience to drops. Make those decisions up front and offline works the way users need it to in the field. Skip them and flip the toggle, and you get an app that demos fine on the office wifi and loses data the first week it is used where it was actually meant to be used.
Offline is a strategy, not a switch. The teams whose field apps hold up are the ones that designed the offline behaviour as carefully as the online one.
