Dynamics 365 and Power Apps Offline: Building Field Apps That Do Not Lose Data

Why do field app records disappear when technicians work offline?

Offline data loss feels random to the people living it, because the app looks normal right up to the moment somebody asks where Tuesday's job sheets went. It is not random. Almost every case we investigate traces back to one of four mechanisms, and each one leaves a recognisable symptom. None of them is fixed by telling technicians to sync more often.

Which offline model are you running: Field Service mobile offline profiles or a canvas app?

The fix depends on which sync engine is doing the work, and many estates run more than one. Establish this first, because advice written for one model is often wrong for the other. Whether Power Apps or a dedicated inspection platform is the right tool in the first place is a separate decision, compared in our field inspection app cost comparison.

What is the durable pattern for an offline field app that cannot lose data?

The pattern is the same whichever model you run; what changes is how much of it the platform does for you and how much you build. On the Field Service mobile app most of the queue is the platform, and the work is in the data model, conflict ownership and visibility. On a hand built canvas queue every step below is your code. These are the steps we build to.

• 1. Write every submission to a durable local queue first. The Submit button saves to storage on the device, never straight to the server. In the Field Service mobile app and in offline first canvas apps on Dataverse the platform keeps that queue; in a canvas app with a hand built queue it means SaveData after every change, not only when the app closes. The technician sees "saved on this device" immediately and "synced" later, as two different states.
• 2. Give every record a client-generated unique key. Generate a GUID on the device at the moment of capture and store it on the record, either as the Dataverse row ID supplied on create or in a column that carries an alternate key. The key belongs to the piece of work, not to the attempt to send it, so every retry refers to the same record.
• 3. Stamp metadata on every record. Store the device identifier, the signed in user, the captured time from the device, the app version and a sync status on the record itself. Stamp a received time server side as well, for example in a plugin on create. Comparing captured and received times is how you spot clock skew and late syncs without asking the technician.
• 4. Send with idempotent upsert. Create or update by the client key rather than blindly creating. A resend after a timeout, a double tap or a retry storm then updates the same row instead of producing a duplicate work order, time entry or parts line. The same rule applies to anything downstream, such as a flow that posts consumption to an ERP.
• 5. Retry explicitly and keep failures visible. Check the result of every write (in canvas apps, IfError or Errors after each Patch), keep failed items in the queue with the error text, retry on reconnect, and never drop an item because a single attempt failed. Anything that fails for a reason a retry cannot fix goes to an exception list that a named person owns.
• 6. Prefer inserts to updates in the data model. Parts consumed, measurements, service task results, time entries and notes are child records. Two people adding child rows to the same job never collide; two people editing one shared field always will. Most conflicts are designed out here rather than resolved later.
• 7. Publish a reconciliation view. Show the technician what is still waiting on the device, and show the back office what was completed on a device but never received, last successful sync per person, and the exception list. Data that fails loudly is recoverable; data that fails silently is how work goes uninvoiced.

How should sync conflicts be resolved, and when is last-write-wins acceptable?

The Field Service offline client tracks changes column by column, so two people editing different fields on the same work order do not overwrite each other. Two people editing the same field is different: the later sync wins, silently. That is a reasonable rule for some fields and a data loss bug for others, and the honest answer is to decide per field rather than look for a global setting that makes conflicts go away. Server side plugins count as an editor too: a plugin that recalculates a column on save will beat a technician who has been offline since morning.

How do you reconcile weeks of conflicting edits when crews edited the same job sheets offline?

When crews have worked the same jobs offline for days or weeks, and the back office now holds a version nobody trusts, the goal is not to guess the right answer. It is to recover every contribution, decide the disputed ones deliberately, and leave a trail. We work through it in this order.

• Freeze the damage first: stop reinstalls, sign-outs and device swaps until every device has synced or its pending work has been captured.
• Collect every source: the server records, Dataverse audit history for the affected tables, the pending queues and sync error lists on each device, service reports and photos already produced.
• Build a timeline per job from captured time, author and device, not from the order the server happened to receive changes.
• Split additive data from disputed data: parts, readings, time and notes from different people usually all stand and simply need to exist as separate rows; true disagreements on one value are few once that is done.
• Decide disputed values with the people who own them, and record the decision, the decider and the reason on the record.
• Correct billing and stock only after the job data is settled, so invoices and van stock are adjusted once rather than repeatedly.
• Change the data model and ownership rules before the crews go back out, or the same reconciliation will be needed next month.

What should a reconciliation view show so nothing is lost silently?

Offline failures are expensive mainly because nobody sees them until month end, when work that was done was never invoiced because it never arrived. A reconciliation view turns that into a daily list someone can clear. On Dataverse it is usually a handful of views, a dashboard and a scheduled flow rather than a product. Reading the audit trail on an individual disputed record is easier with a readable audit panel such as our free Easy Audit PCF control.

• Pending on device: the count of unsynced items per technician and the age of the oldest one, visible to the technician before they sign out.
• Last successful sync per person on the dispatch board, with an alert when it is older than a working shift.
• Completed but not received: bookings a technician marked complete, or jobs dispatch expected to close, with no matching completion on the server.
• Captured versus received time gaps, which reveal late syncs and clock skew.
• Exceptions: writes rejected by validation, duplicate detection, a deleted record or a lost security privilege, each with the error text and an owner.
• Resolved conflicts with both values, the decision and who made it.

How do you troubleshoot Field Service mobile offline when technician work is not arriving?

Most reports of offline not working are configuration rather than fault. Three things must be true before a technician is genuinely offline capable: the mobile offline profile has been published after its last change, the user is a member of that profile, and the app has completed a first full sync on that device while it still had signal. A technician with the right license and no profile membership gets no error, just an app that silently works only in coverage, which is why the problem tends to be discovered in a basement. After that, check the playback failures that are not conflicts at all.

• Scope the profile filters to the technician: their own bookings, their territory and a bounded window of service history. A profile that pulls years of work orders per user makes first sync take hours, fills the device and slows every later sync.
• A booking reassigned while the technician was offline can fall outside their profile filter, so their changes come back with nowhere to land.
• A record deleted in the back office cannot be updated, and a duplicate detection rule or business rule added last week can reject the write.
• All of these land in the sync error list on the device, where only the technician sees them, so surface them in the reconciliation view instead.
• Licensing decides who can be offline at all: a full Field Service user license includes the mobile app with offline; Team Members rights do not cover executing work orders; the Field Service Contractor license is deliberately restricted, so check it against the real workflow before relying on it.
• Continuous location tracking leaves gaps while a device is offline or suspended. If arrival and departure evidence matters, stamp the device position onto the booking at the status change, which is a local write that syncs with the queue, and exclude the app from battery optimisation across the fleet.

How do you recover from the CreatedDate in future sync error without losing a day of work?

This error deserves its own runbook because the obvious reaction to it makes the loss permanent. The device created records while its clock ran ahead of the server, the platform rejects a record that claims to have been created in the future, and because the queue is ordered that one record blocks everything behind it while the technician keeps working.

• Confirm the diagnosis: note the last successful sync and the failing record in the app sync status, then compare the device clock with a trusted source and with server time.
• Do not reinstall the app, clear its data or sign the technician out. Each of those discards the local queue, and the unsynced work orders, photos, readings and signatures exist nowhere else.
• Fix the clock properly: date and time set to automatic, correct time zone, then reboot so the clock resynchronises from the network.
• Trigger a manual sync and watch the queue drain; in most cases the rejected record is accepted once the skew is gone and the rest follows.
• If one record stays rejected, capture its contents first (a screenshot if necessary), discard that single change so the queue can move, and re-enter it in the browser.
• Close the hole: enforce automatic network time through Intune or your device management, block manual time changes, and monitor last successful sync per person. A device that keeps drifting belongs out of the rotation.

Should offline field capture run on Dynamics 365 Field Service, Power Apps or a custom application?

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. For offline field work, the Field Service mobile app is the natural choice when work orders, assets and scheduling already live in Dynamics 365, and our Field Service implementation partner page describes how that build and its offline design are scoped. A canvas app on Dataverse fits focused capture such as inspections and shop floor checks, covered in how Power Apps replaces paper forms on the shop floor. A custom application on React, Node.js, PostgreSQL or .NET is the better answer when you need full control of the sync engine and conflict model, the device fleet is outside Microsoft licensing, or the offline workflow is the product itself. In that case the durable pattern above is not optional: it is the specification.

What does fixing an offline data loss problem involve with Solzet?

It starts with a short, remote audit of the live estate rather than a rebuild proposal: the offline profiles and filters, license entitlements per role, the conflict surface in the data model, server side logic touching technician owned columns, device policy, and the sync error backlog nobody has been reading. From that we fix configuration first, then the data model and ownership rules, then add the reconciliation view, and where a canvas app has a hand built queue we rebuild the queue to the pattern above. Solzet delivers remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 and Power Platform work. For manufacturers in Germany and DACH, where works council rules shape what location data a device may capture, see our manufacturing industry page. If offline problems are one symptom of a wider Field Service programme across mixed legacy versions, see transforming Field Service on a legacy estate.