What it does

The decision about whether an app genuinely needs to work without a network, and what accepting that requirement does to the data source, the licence, the design and the support model. Offline is the requirement most often asserted and least often true.

Key facts

• Native offline is a Dataverse capability. Turn on the offline feature in the app and in the tables it uses, attach an offline profile, and the app reads and writes a local copy that syncs in the background. Other connectors aren't supported in offline mode.
• Turning offline on makes the app offline-first permanently: it works from the local store whether or not there's a connection. That's deliberate — it keeps performance and behaviour consistent as users move on and off the network.
• The built-in engine handles conflict detection, delta sync, schema changes and fast launch over large datasets. The SaveData/LoadData alternative handles none of those; you write that logic and the client owns it.
• SaveData/LoadData are bounded by app memory — generally 30–70 MB available on a device. Built-in offline is device-dependent up to around 3 million rows.
• Documented guidance for canvas offline profiles: keep under 200,000 records for performance, fewer than 100 tables, total data under 1 GB, files and images under 4 GB. Above 3 million records isn't supported by the sync.
• Microsoft suggests a custom offline profile once you need more than about 15 tables, rather than relying on the autogenerated one that downloads everything the user can see.
• Offline runs in the native Power Apps mobile players. A canvas app in a browser can't run offline, including a mobile browser.
• Only a subset of Power Fx works offline, and app checker flags the common configuration problems.

When to use / skip

Ask what the user does when the network drops, and listen for whether the answer is "nothing" or "waits ten seconds". Genuine offline requirements look like: engineers in plant rooms and basements, field service in rural coverage gaps, warehouse racking, aircraft, shipping, anywhere a job is physically completed in a place with no signal and can't be deferred. Those are real and offline is worth the cost.

What you'll more often be handed is intermittent connectivity, which is a different problem with cheaper answers — retry logic, tolerant error handling, and a design that doesn't punish a dropped request. Building full offline for flaky Wi-Fi is a large, permanent tax on the solution for a problem that patience solves.

The cost is worth stating plainly before anyone agrees to it. Offline means Dataverse, which means premium licences for every user. It means profile design and maintenance, a security role holding the right read privileges, an ALM path that handles the profile, and a support model for sync conflicts and stale devices. It also constrains the app: a subset of Power Fx, no flows running offline, and relationship handling that doesn't match what you'd write online. If the client is on SharePoint lists and wants offline, the honest answer is that the conversation is about moving to Dataverse, not about turning on a switch.

Configuration decisions

• Whether the requirement is truly offline or actually intermittent. That's the decision; everything else follows from it.
• Whether the data source moves to Dataverse, and who is paying for that.
• Autogenerated profile or a custom one. Autogenerated is a starting point that downloads every row the user can see, with no filters. Anything going through environments needs a custom profile.
• Which tables and which filters go in the profile, driven by what a user needs to complete a job away from the network — not by what the app displays online.
• Which security role carries the read privileges the offline players need, since the standard basic role doesn't have them.
• Whether several apps share one profile so the download happens once across a suite.
• What the conflict policy is in business terms. The platform detects conflicts; somebody still has to decide who wins.

Gotchas

• Background sync only runs while the app is in the foreground with the screen unlocked. Users who lock the phone and put it in a pocket don't get the sync they assume they're getting, and then blame the app.
• Editing and publishing an offline profile doesn't take effect until every app using it is republished.
• Galleries without an explicit sort can come back in a different order offline than online. Set Sort rather than trusting the default.
• The Power Apps for Microsoft 365 capability table lists running canvas apps offline as included, which reads as though seeded licences cover this. The Dataverse-based offline capability described here is premium. Take the licensing guidance from the licensing pages, and treat that table as being about the older local-storage mechanism.
• First sync on a large profile over a mobile connection is a genuinely bad user experience. Plan for a first run on Wi-Fi and say so in the rollout comms.
• Offline can't be retrofitted cheaply. Deciding it in month six usually means revisiting the data source, the profile, the security roles and half the formulas.

Consultant notes

• Get the offline requirement written down with the specific scenario attached, not as a checkbox. "Works offline" in a requirements catalogue is worth nothing; "counts stock in the Rochdale cold store, no signal, twice a day" is a design input.
• Price it as its own workstream. Profile design, role changes, device testing and conflict handling are not absorbed by an app estimate.
• If the answer is no, document why. Offline is the requirement most likely to reappear at UAT with the sponsor claiming it was always in scope.
• Be blunt about the SaveData/LoadData route. It demos well and supports badly, and if you build it the handover document has to say in plain words that conflict resolution is bespoke code the client now owns.
• Test on the actual devices, on the actual network, in the actual building. Offline defects don't reproduce at a desk.

---

Worth revisiting if non-Dataverse connectors ever gain offline support — that would change this recommendation more than anything else