Offline Mobile App with Power Apps for Field Teams

Your technician is in a basement, on a site at the bottom of a valley, or in a metal warehouse where the phone gets nothing. They need to complete an inspection, take photos, get the customer's signature. Today they do it on paper, or on a form that crashes as soon as the network drops, and they retype everything in the evening. An offline mobile app built with Power Apps answers this case, provided you know what it does on its own and what you have to design.

What "offline" really means

An offline app has to do four things: carry the data the technician will need onto the phone, allow data entry with no network, keep those entries safe on the device, then synchronise when the network returns. Each point raises questions. Which data to carry? What if two people edit the same record? What happens if the phone is lost before syncing?

These are not technical questions, they are business questions. That is why offline is decided at scoping, not while testing in the car park.

What Power Apps does natively for an offline mobile app

Power Apps offers two approaches, and you have to pick one from the start.

• Built-in offline, with Dataverse. For a canvas app whose data lives in Dataverse, you enable an offline profile: you declare which tables and filters to carry (for instance "this technician's jobs for the next seven days"). The Power Apps mobile app downloads that data, lets people work without a network and synchronises by itself when the connection comes back. It is the sturdiest approach, and it requires premium licensing.
• Hand-built offline. With the SaveData and LoadData functions, the app stores collections on the device, and you write the queue of pending entries yourself. This works with SharePoint, so without premium licences, but the whole synchronisation mechanism is yours to design and test.

In both cases, offline works in the Power Apps mobile app (iOS, Android), not in a browser. And the app knows whether the network is there or not, which lets you display clearly "offline, 3 entries pending".

Photos, signatures, location: the controls that exist

The field building blocks are there in Power Apps: a camera control for photos, a pen input control for the customer's signature, the phone's geolocation, a barcode scanner. What takes design is what you do with them.

Photos are the first weight problem. Twenty full-resolution photos per job, over ten jobs, and a 3G sync will never go through. Reduce the resolution at capture, cap the number per checkpoint, and send photos last, separately from the data.

The signature is an image. Decide where it lives (a Dataverse file column, a SharePoint document) and what it is worth: a signature on a screen proves presence, it does not replace a formal work order if your contract requires one.

Time-stamped location reassures customers and secures invoicing. But it is requested with the technician's agreement, and recorded at the moment of entry, not continuously.

Sync and conflicts: what you have to decide

This is the most underestimated point. Two technicians open the same equipment record, both offline, each edits a line. Who wins? For a canvas app, the last write wins, column by column, with no warning; conflict detection only exists in model-driven apps.

Good practice is to design so the conflict never happens rather than to manage it: one job record per technician and per visit, never a shared record edited by several people. Reference data (sites, equipment, customers) goes down to the phone read-only; entries come back up as new records. With that split, conflicts almost disappear.

An audit or inspection checklist, with photos and signature, is a good starting point: our audit and inspection template shows what this kind of app looks like once in place.

Where to start

List the checks your teams do on paper and count what gets retyped in the evening. Then settle two points before anything else: where the data lives (Dataverse or SharePoint, which decides the offline approach and the licensing) and how records are split to avoid conflicts. A short scoping is enough to decide, and our method describes how we then test with real technicians, in the field.