Offline sync behaviour and conflict handling

What it does

Once the offline profile has done its first download, the Field Service mobile app runs offline-first: it reads and writes to a local database and reconciles with Dataverse on a schedule. Sync is per-table, on an interval you set, with a separate up-sync for local changes and a conflict setting that decides who wins when both sides edited the same row.

Key facts

Sync frequency is set per table inside the offline profile and ranges from 5 minutes to 1 day. The shipped profile already has sensible per-table intervals.
Related tables drag each other along. A low interval on a related table effectively overrides the higher interval you set on its parent, so one aggressive table can pull the whole branch down to its cadence.
Three sync passes matter: the first-time download, delta sync (server changes down), and up sync (local changes up). Delta and up sync run in the background while the app is open and connected, and continue in the background on iOS and Android once started.
Conflict detection is a mobile client system setting, Set conflict detection for mobile offline synchronization. Default is No, which means the offline change overwrites the server. Set to Yes and the server wins, and the technician sees a sync error.
Conflict resolution is row-level, not column-level. If the dispatcher changed the scheduled time and the technician changed the resolution notes, the whole row is the unit of conflict.
Three toggles live on the app's Features tab: Allow users to adjust sync frequency, Allow users to sync on Wi-Fi only, and Allow users to work in online mode.
Wi-Fi-only is not absolute. When a push notification arrives, the app syncs over cellular regardless of that setting.
Rows leave the device silently when they stop matching the profile filter — a completed booking dropping off after the next delta is normal behaviour, not data loss.
Resetting the app clears the local database entirely and forces a full first-time download.
Sync status lives behind the globe icon in the app navigation on Windows, iOS and Android: last sync per table, error messages, and a manual Sync now.
Sync telemetry can be pushed to Application Insights; Microsoft publishes the mobile sync telemetry events and a sample Field Service dashboard.

When to use / skip

Nothing here is optional — you're configuring it whether you think about it or not, since the defaults apply on day one. What you do choose is how much control the technician gets. Handing users the sync frequency toggle sounds friendly and reliably produces one technician on a 24-hour interval wondering why their bookings are yesterday's. On most projects, leave user-adjustable frequency off, leave Wi-Fi-only off unless the client is paying for metered data plans, and decide deliberately about online mode.

Online mode is the one genuinely contested choice. It gives supervisors and office-based users live data, but it means two different behaviours to support and two sets of bug reports. If the mobile app is only for technicians in the field, don't enable it.

Configuration decisions

Per-table intervals: which reference tables can sit at daily, and which transactional tables need to be near-live.
Conflict detection Yes or No — in practice, whether a dispatcher's reschedule should be allowed to be overwritten by a technician's stale device.
Whether technicians can adjust their own sync frequency, and whether Wi-Fi-only sync is offered.
Whether online mode is available at all, and to whom.
How long completed work stays visible on the device before the filter drops it — this is a profile filter decision, but it surfaces as a sync complaint.
Whether you wire Application Insights up front, or wait until you have a sync problem and no data.

Gotchas

The default conflict setting means last-writer-on-the-device wins. Clients almost always assume the opposite. Get this decision written down, because changing it later changes behaviour for everyone at once.
Row-level conflict resolution means a technician's booking update can quietly revert a dispatcher's field on the same row. This is the single most common "the system lost my change" report.
Overly tight profile filters produce "record not found" errors rather than empty lists, which reads as a bug.
Large first-time syncs can time out, and a synchronous plugin or ISV logic firing on up sync will fail the whole sync rather than the one row. Check third-party plugins registered on the tables in the profile.
A booking status table missing from the profile breaks status changes offline — the app looks functional right up to the point the technician tries to complete work.
If the device boots before the network stack settles, the app can start offline and report "Network or Service Unavailable" even though the phone has signal. Retrying is usually the answer; users escalate it as an outage.

Consultant notes

Set the expectation early that offline is eventually consistent. Dispatchers who expect the schedule board to reflect a technician's tap within seconds will be disappointed, and that's a design conversation, not a defect.
Demo the globe icon and the device status page during training. Most sync incidents are self-diagnosable there and never need to reach support.
Before go-live, run a deliberate conflict test: dispatcher edits a booking while the device is in flight mode, then reconnect. Show the client the outcome and confirm they accept it.
Push back on requests to sync everything every five minutes. It burns battery, floods Dataverse, and makes the first sync worse for every new starter.
Check plugin and flow behaviour on up sync before UAT — logic written for the web app often assumes a user context and an immediate response that offline sync doesn't give it.

Worth another look if the client changes conflict detection, or if sync times start creeping up after a data growth spurt.