"My data looks wrong" and "my data is missing" span several different subsystems, and the fastest route to the right one is to pin down the shape of the problem before touching anything. Three questions do it: who sees the problem (one user, or everyone?), where it shows (the web, a device, or both?), and what kind of number it is (a record you can open, or a computed figure in a report or stock screen?).
Pin down the shape
- One user is missing what colleagues can see → it is access, not data. Go straight to Troubleshooting: a user can't see something and work its layers in order.
- The web and a device disagree → it is sync or offline scope. Skip to the mobile section below.
- A computed figure looks wrong — a report total, a dashboard tile, a stock balance → skip to the last section; those numbers have their own reading disciplines.
- Everyone is missing the same records on the web → start with the next section.
On the web: filters, access, deletion, imports
Check the view before anything else. Saved view filters, personal column filters, leftover search text and date-range scopes hide records with no fault anywhere. Switch to an unfiltered view, clear filters and search, and compare the count — if the records appear, adjust the view and stop. A shared view's default filters can surprise a whole team at once.
A record that used to exist may be deleted. Deleting in xMatix is soft: the record disappears from every list, report and lookup immediately, but sits in the entity's recycle bin for a retention window — 30 days by default — from which anyone with delete permission on the entity can restore it, children included. Check the recycle bin before concluding data was lost, and treat the window as a real deadline. See Delete, recycle bin, archive and restore.
Recently imported data has a per-row audit trail. If the missing or wrong records were loaded by import, don't guess — read the run. Setup → Administration → Data Import → History keeps every run with its status, its created/updated/errored counts and a message per failed row; rows fail individually, so a PartiallyCompleted run has still written its good rows. Duplicates after a re-import usually mean the file lacked record ids. See Import data.
On mobile: scope first, then the queue
Two different things get reported as "data missing on my phone", and they have different fixes.
A record visible on the web but absent on the device is usually the offline scope, not a fault: the app keeps a configured subset — reference data plus a recent window of transactions — and some record types are online-only. Access is identical on both surfaces (one account, one set of permissions), so if the user can open the record on the web, the question is only whether the device has downloaded it. See Troubleshooting the mobile app.
A change made on the device that hasn't reached the server is a queue question. The Sync Status screen shows the last sync time and every queued change with its state; pending items go out on their own once the device reconnects, but an item flagged needs attention — a validation rejection, or a conflict with a concurrent edit — waits for the user to fix and resend it or discard it. Until a change has synced it exists only on the device, so this screen is the truth about what the server has. The full walk-through is Working offline: sync status and recovery, and the design behind it is How offline-first mobile works.
Administrators get the fleet view. Terminal sync failures are filed server-side as Mobile Sync Failure records — entity, operation, error, payload, device — so you can see what is failing across all devices without waiting for reports. Reading and triaging them is covered in Monitoring mobile sync failures.
Data that syncs with another system
When the wrong-looking records are kept in step with an external system, check the sync before editing anything — a conflict freezes that record in both directions until someone decides, and a lagging watermark means the engine simply hasn't caught up. The Sync Monitor (Setup → Platform Operations → Monitoring → Sync Monitor) has a Health tab showing lag, failed streaks and parked records per profile, and a Conflicts tab listing every record the engine refused to decide — expand a row to see only the contested fields, base, xMatix and external side by side, then choose a side, record a manual merge or park the record. Its counters distinguish open conflicts from ones re-detected across several cycles and from delete-versus-update collisions; an empty Conflicts tab means the selected profile and entity scope has nothing awaiting a decision, not that sync is healthy — read Health for that. Do not edit the business record first: that can erase the evidence needed to understand why synchronization stopped. How to read both, and how to drill a failed run down to the step that broke, is in Sync health, conflicts and failed runs; symptom-first fixes are in Troubleshooting integrations.
Computed figures: reports and stock
Analytics numbers are read through their own pages: a report with no rows or a blank dashboard has a checklist in Troubleshooting analytics, and stale warehouse-side datasets — figures that lag the operational system — are covered in Troubleshooting Data Studio.
Stock balances are the running sum of posted ledger entries, so a surprising figure is explained by a row, not by a fault: open the Ledger console, pick the item and date range, and the movement that produced the surprise is in the list. Pairs of opposite entries are corrections, not errors — read them together. The reading discipline is in The inventory ledger, and the working method in Troubleshooting inventory.