When a change queued on a device fails terminally — the server rejected it, or it conflicted with a concurrent edit and its retries are exhausted — the device does two things. It flags the change to the user on their Sync Status screen, where it stays until they fix or discard it; and it files a Mobile Sync Failure record on the server for you. That second half is this page: the fleet-wide view of what is failing to sync, without waiting for users to report it. The report itself is sent through the same store-and-forward queue as everything else, so a failure that happens offline still reaches you once the device reconnects.
Only terminal failures are reported. Transient errors — network drops, timeouts, server hiccups — retry automatically on the device and never appear here; a queue that is merely waiting for connectivity produces nothing. One record is filed per failed attempt, deduplicated, so a change the user fixes and resubmits into a second genuine failure produces a second record rather than noise.
The record
Mobile Sync Failure is an ordinary entity — browse it as a list, filter it, build views and reports over it. Open Mobile Sync Failures from the navigation of whichever app your administrator placed it in (it may sit under More), or search for it in the App Launcher. Its fields:
- 1
Mobile Sync Failure is an ordinary entity list: filter it, build views and reports over it, and open a row for the full payload and error.
- 2
Name summarises entity and operation; Source Entity and Operation (Create, Update, Delete, Action, UploadFile) say what the device tried to write.
- 3
Failure Reason: Rejected means the server refused the change; Conflict means the record changed underneath the edit. Each needs a different response.
- 4
Resolution Status is your triage state; new reports arrive as Open and nothing here re-sends the device's queued change.
- 5
Device identifies the reporting device; several rows from one id point at a device or app-version problem rather than a rule.
- 6
Attempt Count and Last Attempt (UTC) separate instant refusals (1 attempt) from exhausted retries, like the Order create that failed five times.
The list is the fleet-wide triage queue. In the example above nine Open, Rejected failures cluster on three devices: repeated CheckInInspection creates from one device within two minutes, and an Order create that exhausted five attempts — exactly the patterns the triage section below reads. An empty list means no terminal failure is currently recorded in the selected view; it is not the device's live pending queue.
| Field | Meaning |
|---|---|
| Name | Summary headline — entity and operation, e.g. Order Create failed |
| Source Entity | The entity the queued change targeted |
| Source Record Id | The record involved — a device-generated id when a create never reached the server |
| Operation | Create, Update, Delete, Action, or UploadFile |
| Failure Reason | Rejected (the server refused it) or Conflict (the record changed on the server underneath the edit) |
| Attempt Count | How many times the device tried before giving up |
| Error Message | The server's error, as the device recorded it |
| Payload | The queued change itself, as data (long payloads are truncated) |
| Occurred (UTC) | When the change was originally queued on the device |
| Last Attempt (UTC) | When the final attempt failed |
| Device Id | The reporting device |
| User Name | The signed-in user |
| App Version | The app build that filed the report |
| Resolution Status | Your triage state; new reports arrive as Open |
Open one report to read its full payload, error and timestamps together before changing Resolution Status. The detail is evidence only: editing or resolving this server record does not retry or discard the original device outbox item.
How to triage
Start with Failure Reason, because the two values call for different responses.
Rejected means the server said no and retrying cannot change that — a validation or business rule the user could not evaluate offline, a permission gap, or a reference to something deleted or renamed. Read Error Message for the rule, and Payload for exactly what the device tried to write; between them the cause is usually plain. Fix the root cause where there is one (a rule that cannot be satisfied offline, a missing permission, stale configuration), then have the user resolve their side: the change is still sitting on their device under Needs attention, and their Fix and Retry actions are described in Working offline. The resolution always completes on the device — the queued change belongs to it, and nothing you do to the report re-sends it.
Conflict means two people edited the same record and the device's edit lost the race. There is rarely an administrator-side fix; the value of the report is visibility — which records and teams collide, and how often. The user decides on their device whether to keep or discard their version. Recurring conflicts on the same records are a workflow signal: two roles both editing what one should own.
Use Resolution Status to run the queue: work Open records, and record the outcome as you go so the list stays a to-do rather than an archive. The remaining fields are for patterns rather than single cases — the same Source Entity across many users points at a rule or configuration problem; clusters on one Device Id or an old App Version point at a device or an update that has not landed; Attempt Count and the two timestamps tell you whether failures are instant refusals or long-suffering retries.
What this is not
This is not a live view of the sync pipeline. Changes that are pending, in flight, or retrying exist only on their devices — visible to each user on their Sync Status screen — and a healthy fleet files nothing here at all. It is also not a recovery mechanism: the report carries the payload as evidence for diagnosis, but replaying data into the system from reports would bypass the user's decision about their own queued edit. Treat an empty Mobile Sync Failure list as the success condition, and the occasional record as a specific, well-documented conversation to have.