This page helps you find the cause when data in xMatix looks wrong or seems to be missing. Problems of this kind come from several different parts of the platform, so first find out what shape the problem has, then go to the section for it. Three questions are enough: who sees the problem (one user or everyone), where it shows (the web, a phone or both), and what kind of figure it is (a record you can open, or a number calculated in a report or stock screen).
Overview
| What you see | Where it comes from | Start here |
|---|---|---|
| One user is missing records that colleagues can see | Access | Troubleshooting: a user can't see something |
| Everyone is missing the same records on the web | The view, a delete, an archive rule or an import | On the web |
| The web and a phone disagree | Offline data on the device or the sync queue | On mobile |
| Records kept in step with another system look wrong | Integration sync | Data that syncs with another system |
| A report total, dashboard tile or stock balance looks wrong | A calculated figure | Computed figures |
When to use it
- A record you expect is not in a list, lookup or related list.
- A record you created or changed on the phone has not appeared on the web.
- Records loaded by import are missing, wrong or duplicated.
- Records synchronized with another system have stopped updating or show the wrong values.
- A total or a stock balance does not match what you expect.
Prerequisites
- To read Import History you need the data-import capability, which shows Import under Setup → Platform → Data.
- To read the server copy of failed mobile changes you need read access to Mobile Sync Failure records.
- The Sync Monitor needs the Manage integrations capability.
- The Recycle Bin opens from the App Launcher.
On the web
Work through these checks in order. Each one is quicker than the next, and the first one solves the problem most often.
Step 1 — Rule out the view
Saved view filters, your own column filters, search text left in the box and date-range scopes all hide records without anything being wrong. Switch to an unfiltered view, clear the filters and the search, and compare the record count. If the records come back, adjust the view and stop there. A shared view with default filters can hide the same records from a whole team at once.
If a colleague with the same view can see the record and you cannot, the cause is access, not data. Go to Troubleshooting: a user can't see something and work through its layers in order.
Step 2 — Look in the Recycle Bin
Deleting a record in xMatix is a soft delete. The record leaves every list, lookup, related list and report straight away, but it stays in the Recycle Bin (App Launcher → Recycle Bin, then the entity) until its Purge After date. That date is 30 days after the delete by default.
- Restore is row by row. Records deleted together are not restored together. If you deleted an order line and its parent, restore each of them.
- Reason is usually empty. An ordinary delete leaves Reason blank ("—"). It is filled in only when the platform removes a record itself as part of a process.
- After Purge After the record leaves the Recycle Bin. It is kept in a retention archive, and only a platform operator can bring it back. Recovered rows come back into the Recycle Bin, where you restore them as usual.
Check the Recycle Bin before you decide data was lost, and treat the Purge After date as a real deadline. The full delete-and-restore path is in Delete, recycle bin, archive and restore.
Step 3 — Check whether an archive rule retired the records
An archive rule moves old rows of one entity to the analytics warehouse on a schedule, and removes them from the working database. Those rows never appear in the Recycle Bin and cannot be restored. They are read-only history. To read them, use a list view whose Read rows from setting is Archive, or a report or dashboard with its Live / Archived switch set to Archived. If records older than a certain date vanished on the same day, ask your administrator which archive rules are active on that entity.
Step 4 — Read the import run
If the missing or wrong records were loaded by import, read the run instead of guessing. Go to Setup → Platform → Data → Import. The page body is the Import History table. Each run shows its Status, its Type (Sync, Async or Dry run), its created, updated and error counts in Result, and a Failed Rows download with one message per refused row.
- Rows fail one by one. A Partial run has still written its good rows. Download the failed rows, correct them and import only those.
- A Dry run saves nothing. If the run's type is Dry run, no record was written.
- An Import now run stuck at Processing means the browser tab closed during the run. The rows written before that stay, and nothing on the server finishes the run.
- Duplicates after a re-import mean the file had no way to match existing records. An import updates a record when the row carries its record id, or, on entities with an external id, when the external id matches exactly one record. Every other row creates a new record.
The wizard and every column of Import History are covered in Import data with the import wizard.
On mobile
Two different problems are both reported as "data missing on my phone", and they have different fixes.
Step 1 — A record is on the web but not on the phone
When the phone is online, its screens ask the server first and use the copy on the device only when there is no connection. So if the phone is online and a record is still missing, check the screen's filters and search on the phone, as you would on the web. Access is the same on both: one account and one set of permissions.
When the phone is offline, it can show only what it downloaded. The app keeps only the record types its offline configuration lists. It keeps master data in full, and transactions for a recent window. A record type with too many rows to download stays online only. See Troubleshooting the mobile app and How offline-first mobile works.
Step 2 — A change made on the phone has not reached the server
This is a question about the queue of changes waiting to sync. Open Sync Status. Its Changes line summarises the queue, for example 1 needs attention · 3 waiting. Tap it to open Pending changes, which lists every queued change in two groups:
- Waiting to sync: the change goes out on its own once the phone reconnects.
- Needs attention: the change waits for you. It is Rejected (the server refused it, or five attempts failed), Conflict (someone changed the same fields on the server) or Blocked (it depends on a related change that failed).
Until a change has synced, it exists only on the phone, so Pending changes shows exactly what the server does not have yet. Fix and resend a rejected change, use Keep mine or Discard for a conflict, and deal with the failed parent of a blocked change first. Discarding the parent does not release the blocked changes, so discard them too. The full walk-through is Working offline: sync status and recovery.
Step 3 — For administrators: look at every device at once
Changes that end up under Needs attention are also filed on the server as Mobile Sync Failure records. Each record holds the entity, the operation, the error, the payload and the device, so you can see what is failing across all devices without waiting for users to report it. An administrator can settle a failure from the server: Resolved or Won't Fix removes the change from the phone, and Retry sends it again. The phone picks up the decision on a later sync, provided the user can read Mobile Sync Failure records. See Monitoring mobile sync failures.
Data that syncs with another system
When the records that look wrong are synchronized with an external system, check the sync before you edit anything. A conflict freezes that record in both directions until someone decides, and a sync that is behind simply has not caught up yet. Do not edit the business record first, because that can erase the evidence of why synchronization stopped.
Open Setup → Platform → Monitoring → Sync Monitor:
- The Health tab shows lag, failed streaks and parked records for each sync profile.
- The Conflicts tab lists every record the engine would not decide for you. Expand a row to see only the contested fields, with the base, xMatix and external values side by side. Then choose a side, record a manual merge or park the record.
An empty Conflicts tab means nothing in the selected profile and entity scope is waiting for a decision. It does not mean sync is healthy, so read Health for that. A profile that never runs is often a profile that was activated but not compiled, because schedules are switched on and off only when the profile is compiled. See Sync health, conflicts and failed runs and Troubleshooting integrations.
Computed figures
Analytics figures each have their own page. A report with no rows or a blank dashboard has a checklist in Troubleshooting analytics. Warehouse datasets that lag behind the working system are covered in Troubleshooting Data Studio. A report or dashboard set to Archived shows only rows that archive rules moved, not live records.
Stock balances are the running sum of posted ledger entries, so a surprising figure is explained by a ledger row, not by a fault. Open the Ledger console and pick the item and date range. The movement behind the figure is in the list. Pairs of opposite entries are corrections, not errors, so read them together. See The inventory ledger and Troubleshooting inventory.
Example
A sales coordinator reports on Monday that last month's orders for one region are "gone". The administrator works the triage:
- Colleagues are missing the same orders, so it is not access.
- Clearing the view's filters changes nothing.
- The Recycle Bin has no deleted orders from that month.
- The orders are older than a date cutoff, and they all vanished on Sunday night. An archive rule on orders ran on Sunday. The administrator switches the coordinator's report to Archived, and the orders are there as read-only history.
The fix is to change the rule's cutoff if the team still needs those orders live. Archived rows themselves cannot be brought back.
Training
Practice exercise
In a sandbox, delete one test record, then find it in App Launcher → Recycle Bin and note its Purge After date. Restore it and confirm that it is back in its list. Then import a three-row file with one deliberate error as a Dry run.
Expected result: the restored record appears in its list again. Import History shows a Dry run row with one error, and no record was created.
Quick reference
- One user missing records → access. Everyone missing records → view, Recycle Bin, archive rule, import.
- Clear view filters and search before anything else.
- Deleted records stay in the Recycle Bin until Purge After (30 days by default), and are restored row by row.
- Archived records are never in the Recycle Bin. Read them through an Archive view or the Archived switch.
- Import History: Setup → Platform → Data → Import. Partial runs keep their good rows.
- On the phone: Sync Status → Changes → Pending changes. Anything under Needs attention waits for you.
- Integration data: read the Sync Monitor before you edit the record.
Common questions
Can I get a record back after its Purge After date?
Not yourself. After Purge After the record leaves the Recycle Bin and goes to the platform's retention archive. A platform operator can recover individually identified rows from there. Recovered rows return to the Recycle Bin still deleted, with a fresh 30-day window, and you restore them as usual. Related rows come back only if they are named too, so list every record you need when you ask. Records that an archive rule moved are a different case: they are read-only history and are never restored.
Why does my phone show a record my colleague says was deleted?
While the phone is online, screens ask the server first, so a deleted record disappears as soon as the screen reloads. While the phone is offline, it shows the copy it downloaded earlier, and that copy catches up on the next sync. If the record still shows after a successful sync, check whether it was really deleted on the web. Look in the Recycle Bin.
Does an empty Conflicts tab mean my integration is fine?
No. An empty Conflicts tab only means that, for the profile and entity scope you selected, no record is waiting for a decision. A sync that is failing, or that has stopped running, can still show an empty Conflicts tab. Open the Health tab of the Sync Monitor to see lag, failed streaks and parked records, and drill into a failed run to find the step that broke.