Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Why your power app goes dark the moment the signal drops. A mechanic in a truck yard with no signal is still tapping through an app. That app is a power app, and it never saw a single bar of service all day. Most apps stop dead the moment the internet does, which is a real problem if your team works in warehouses, basements, or anywhere, the signal drops. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Today, we're breaking down Power Apps offline mode, the feature that lets an app keep working with no connection at all. One choice decides whether it works for you, and it happens before you build anything. To see why offline mode matters, start with how power apps normally work. Every app reaches out over the internet to grab the data. It shows you whether that data lives in SharePoint, in a database, or in Dataverse. That design keeps everything current and shared across your whole team, which is exactly what you want in an office. It falls apart the second the network does, because there's nothing local for the app to read. Offline mode is the answer to that gap. It means the app stays useful when there's no connection, because it runs on a copy of the data stored on the device itself. Instead of asking the cloud for every screen, the app asks the phone, and the phone always answers that single swap is the difference between an app that quits and an app that keeps going, and it's why a crew can work a whole shift without ever seeing a signal bar. I want you to picture who this is really for, because it isn't a rare edge case. Think about a technician inspecting equipment in a basement with no signal, a delivery driver scanning parcels in a dead zone, or a nurse updating a form in a hospital wing where the WiFi keeps dropping. Those are the jobs where a normal app turns into a paper notebook, and that's where offline mode earns its keep. It changes how you design an app from the very first screen. And there's one decision sitting underneath all of it. Most people make that decision before they realize they made a choice at all. The one choice that makes offline possible the decision is your data source, which is simply where the apps information lives. If your app is built on Dataverse, offline mode comes built in. Dataverse is Microsoft's data layer for power platform, the shared home for your tables, and it's the only source. The built in offline feature speaks one word of warning about that name Dataverse. It sounds like a separate product you have to go and buy. And in a way, that's true. But you don't need to be a database expert to use it. You create tables with columns the same way you would in a spreadsheet, and PowerApps treats those tables as the source of truth for everything the app shows. If your app lives on SharePoint, on Soql, or on some other connector instead, the built in offline switch won't help you. Those sources stay online only, and Microsoft is direct about it. Non Dataverse connectors like SharePoint aren't supported in offline enabled apps. That doesn't mean offline is impossible without Dataverse. There's an older path where you hand build the whole thing with two power effects functions save data and load data, which save a collection of data to the device and load it back again. It works, and it has a hard ceiling that saved data sits in the app's memory, and you generally get about thirty to seventy megabytes to play with. That's enough for a few text fields, and nowhere near enough for images. And you have to write the conflict handling yourself because nothing does it for you. So the easy path is Dataverse and the hard path is everything else. Most beginners hear the words offline mode and assume it works with whatever they already built. That assumption is the first thing that costs them a week. There's one more condition sitting on top of this choice that offline support only works in the PowerApps mobile app, on a phone or tablet, on iOS, Android or Windows. Open the same app in a web browser, and offline simply isn't there even on a phone. And the app has to live inside a solution, which is the container Microsoft uses to move an app safely between environments. With that choice made, the next question is what actually happens on the device? The answer has very little to do with the cloud, and everything to do with a copy of your data that sits on the phone. How the app keeps working with no internet at all. Once you've chosen Dataverse, the magic is a lot less magical than it sounds. The app doesn't reach the cloud without a connection because that's impossible. What actually happens is that the data comes down to the phone before you ever need it. Microsoft calls this offline first, and the name is the whole idea. All the data you might need while offline gets copied to the device first, which means you need a working connection at least once. After that first download, the app reads and writes to the copy on the phone. Whether you have five bars or zero, moving in and out of signal doesn't slow the app down because the app is barely waiting on the network at all. The real question is how much data comes down, because you can't drag a million records onto a phone and expect it to be happy. That's what the offline profile handles. An offline profile is a set of rules that says which tables and columns are available offline, and which rows actually get copied. It works like a filter you set as the maker. So a field technician only carries the work orders and the customers that belong to them. For a small app, PowerApps can generate that profile for you, and it works well when the data set is modest. For a bigger app, you build a custom profile to keep the download lean. The rule of thumb from people who do this for a living is simple. If a table holds more than a few thousand rows, filtering stops being optional and starts being the job. The copy itself sits in a small database on the device, and that local copy becomes the app's main source of truth. Every gallery, every form, and every search reads from it, which is why the app can feel fast even on a weak connection. There's one requirement that surprises people, and it's worth saying plainly a user has to open the app once while connected to pull the data down. If someone installs the app and drives straight into a dead zone, they'll open it to nothing. The download has to happen first. That first download is worth planning around because it isn't instant, depending on how much data is in the profile and how good the connection is, the initial sync can take several minutes. It's not something you want to start in the parking lot five minutes before the crew heads out. One more detail saves an afternoon later. The rows on the device don't always come back in the order you expect, so it's worth sorting them inside the app rather than trusting the sync to do it for you. That copy does a lot of work in the background, and most of the time you never think about it. The moment it earns its money is the moment something goes wrong. What happens when a sync fails? And what happens when two people touch the same record is the part that separates a smooth rollout from a messy one. What happens when the signal comes back? Now for the part that worries people most, which is what happens to everything you typed while you were offline. Nothing is lost and the reason is the design. When you save a change with no connection, the app doesn't fail it cuz that change on the device and the moment the network returns, it pushes the change up to Dataverse for you. If you happen to be online when you save, the app still writes locally first and syncs in the background so the app stays responsive. Either way, the syncing itself is smarter than a full copy each time. Once that first download is done, the app only pulls down. What changed since the last sync, which Microsoft calls incremental sync? You can also set how often each table checks in anywhere from every few minutes to once a day. If nothing has changed on the server. The app skips that sync entirely to save your data and your battery. So far, that all sounds calm. Here is where two people can bump into each other. Imagine you fix a customer's address offline. At the same moment an office colleague edits the same address online. You have two edits on one record, and a clash seems inevitable. Dataverse settles it by keeping the last update to each column so the sync doesn't fail and you don't get an error. Whichever edit was saved last on that column is the one that sticks. There's a limit to that column. If a server side rule or a plugin rejects your change, the app rolls the change back on your device and writes an entry into a table called sync error, which an admin can review and retry later. It isn't a silent failure, and that matters because silent data loss is the fear that keeps people away from offline apps in the first place. The old way of doing offline made this worse. It gave users a toggle called work in offline mode, and if they forgot to switch it off and sync, their work could sit stranded on the device. The newer offline first approach removes that toggle entirely so nobody has to remember anything. Users aren't left guessing about any of this either. The mobile app shows a small sync icon that tells them whether they're connected, whether changes are still waiting to go up, or whether a sync hit a problem. The state of their data is never a mystery, and that alone removes most of the anxiety people feel about working offline. What a real offline app looks like. Abstract features are easy to nod at and then forget. So picture the mechanic from the start of the episode. He walks the yard with a tablet, and for each truck he opens an inspection screen, taps, pass or fail, types a short note, and moves on. There's no signal in that yard and it doesn't matter. Every tap lands on the copy stored on the tablet, and when he drives back into town, the app syncs every inspection up to Dataverse before he has even parked. That isn't a toy. Example. One documented project turned a canvas app with about forty Dataverse tables and around thirty screens into a fully offline field tool covering things like logging hours, running risk assessments, and updating maintenance tasks that team can spend the whole day disconnected and lose nothing at all. There's a simpler version, too, and it's the one most beginners build first, an asset management app lets a worker scan a piece of equipment, view its details and update its status, all without a connection. The win here is simple the work never stops just because the bars disappear. If you're picturing your own team right now, that's the right instinct because offline mode is really about matching the tool to the place. If your people work where the signal is reliable, you probably don't need any of this. If they work where it isn't, it changes everything. There's a quiet benefit on the office side to every inspection lands in Dataverse like any other record, so the people back at head office can report on it or trigger an automation from it the same way they would if the data had been typed online. So the field side works beautifully. That's exactly why the limits sting when you finally hit them. There are a few things offline mode simply can't do at all, and knowing them before you build will save you a costly rebuild down the road. What offline mode can't do. Now comes the honest part, because a feature you don't understand the edges of is a feature that will embarrass you later. The biggest limit is the one we already met. Built in offline is Dataverse only, and it's mobile only. If your data sits in SharePoint or your users work in a browser. This path is closed to you. There's also a ceiling on volume. Dataverse caps offline sync at three million records in total, and that count includes some hidden tables the platform uses behind the scenes. That sounds enormous, and for most field apps, it truly is. For a very large data set, it means you filter hard with your offline profile and carry only what the day actually needs. A surprising number of everyday features don't come along for the ride. Personal views are out, so users get the system views and quick views and not the private ones they build for themselves. Advanced lookup is replaced by a simple dropdown field level security isn't supported offline, and duplicate detection and merging don't work. Grid column filtering is switched off too, so the grid works from the local data with no custom filters. Search is a different story. Dataverse search doesn't run offline at all, and the app falls back to a simpler search that looks at one table at a time and needs exact matches. A typo that would still find a match online will find nothing here. A few things update late rather than never calculated, and rollup fields don't recalculate on the device, and they only refresh once the row syncs back to Dataverse fields that are normally mapped from another table don't prefill. When you create a new record offline. The offline profile itself has a shape limit as well, with a maximum of fifteen relationships per table and no circular or self-referencing links. None of this makes offline mode a bad choice. It makes it a choice with a shape, and the makers who succeed are the ones who learn the shape before they start building the mistakes that catch people out. Knowing the limits is half the battle. The other half is avoiding the traps that people walk into over and over. The first trap is assuming any data source works offline. People spend days trying to make a SharePoint list sync offline with the built in feature, when that feature was never going to help them check the source before you check anything else. The second trap is trusting the auto generated profile on a large data set. It's fine when the data is small and it falls over when a table holds a million rows, because downloading all of them to a phone is slow, wasteful, and sometimes just won't finish. If your data is big, build one by hand and sync only what the user truly needs. The third trap is building blind and never touching a real phone. Offline apps behave differently on a device than they do in the studio, and half the problems only show up there. The advice from people who have done this is to convert an app one screen at a time, and test each screen on an actual tablet or phone before moving on. The fourth trap is changing the app and the offline profile at the same time. When something breaks and something will break, you won't know which change caused it. Move one piece, test it, then move the next. There's a fifth trap that's less obvious, and it's the one I'd flag for anyone converting an app that already works. Don't treat offline mode as a checkbox you add at the end. If the app was built without it in mind, you may have to rethink the data model, the screens, and even the automations before the offline switch does anything useful. The error messages won't always help you either. The most common one you'll see is a generic line about an error while trying to retrieve data from the network, and it almost always means the app is touching data that isn't in the offline profile. It's rarely about the network at all. I'll be straight with you about the size of the job. Converting a large existing app to work offline is a real project, not a weekend. One experienced maker put it bluntly and admitted he wouldn't recommend it for complete beginners. That isn't a reason to avoid offline mode. It's a reason to start small and prove it on one screen before you bet a whole rollout on it. Where this sits in Microsoft three hundred sixty five and Azure. It helps to know where this tool lives in the Microsoft picture. PowerApps is part of power Platform, the family that also includes Power Automate for automation and power BI for reporting. Underneath all of them sits Dataverse, and Microsoft describes it as the data foundation of the platform. That's why the offline feature leans on it so heavily, because Dataverse is where the tables and the relationships actually live. People often frame this as purely an Azure question or purely a Microsoft three. Sixty five question. It's a bit of both. Dataverse is built on Microsoft Azure, which is why it can scale and stay available around the world. So the cloud doing the syncing is the same Microsoft cloud you already trust with your work on the Microsoft three hundred sixty five side, the app runs in the PowerApps mobile app rather than in teams or a browser. The old save and load path inside teams is capped at one megabyte, which is fine for a handful of text values and not for much else. There's a licensing reality worth naming because beginners get caught by it. Dataverse sits in the premium tier of PowerApps, so this isn't something that comes free with the basic Microsoft three hundred sixty five seat. The free developer plan is for building and testing, and running an app for real users means a premium plan. I won't quote you a price because those change, but it's worth checking with whoever owns your licenses before you promise a rollout. None of this is meant to scare you off. It's meant to save you from the awkward moment where you build something brilliant and then discover the people who need it can't run it. A short conversation about licensing at the start is worth far more than a week of rebuilding later. So the picture is this. You build on power platform. You store your data in Dataverse, you run the app on a phone through the PowerApps mobile app, and Azure handles the scale underneath. The short version. Here's the whole thing in a few lines. Offline mode means the right data is copied to the device ahead of time. The app reads and writes that local copy with or without a connection, and your changes sync back to Dataverse the moment the signal returns. It works with Dataverse. It runs in the mobile app, and it comes with real limits that are worth knowing before you build anything. Here's the question I want to leave you with. Where do you or your team lose signal and wish the app kept working anyway? That answer tells you whether offline mode is your next project or a feature you can safely skip. If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.