Most mobile surprises come down to one of three honest states: the data was never in the device's offline scope, a queued change needs your attention, or a feature genuinely needs the server right now. The app tells you which — on the Sync Status screen, in a badge, in a plainly-worded message — so the method here is always the same: find what the app is saying before changing anything. Each section below is a symptom, in the order people hit them.
This cross-symptom page stays text-only because the relevant evidence moves between the native entity list, Sync Status queue, sign-in, metadata refresh and Storage & Database screens. One generic responsive-web screenshot would be unrelated to most symptoms. Capture the exact native screen and state named by the symptom when reporting a real incident; do not reuse a healthy list as proof of an outbox or device-storage problem.
For a missing record, first confirm the active app, entity, selected view, recent items and list controls. View selection, search and filters can hide records independently of offline scope, so clear them before escalating to synchronization. Record the app, view, last sync time and connection state; then inspect Sync Status for the entity's offline mode, age window and queued failures. Include the row's reference code when reporting a rejected change, but redact customers, insights and search terms from support screenshots.
A record shows on the web but not on mobile
Your access is not the issue — permissions are identical on both surfaces. What differs is what is stored on the device, and that is configured per record type:
- Check the record type's row on the Sync Status screen's offline data card (how to read it). Off means your organization does not keep this type on devices; Manual means it syncs when you tap the row; a missing row means the type is outside the offline scope entirely.
- Check the age. Transaction-type records are kept for a rolling window — an order from last year may be older than the window and legitimately absent, while the customer it belongs to (master data) is fully present.
- Check the last sync time. A record created on the web minutes ago arrives with the next sync — pull down to refresh the list, or tap Sync now.
If the scope itself is wrong for how your team works — a record type you need daily marked Off, a window too short — that is a configuration request for your administrator, who adjusts it centrally in the Mobile App configuration.
My changes haven't reached the server
Open the Sync Status screen and read the Changes card — it distinguishes changes that are merely waiting from changes that need you:
- Waiting to sync items need connectivity and the app in the foreground; they send on their own. The floating pill at the top of the screen is red while you are offline.
- Needs attention items are stopped for a reason the row states — rejected with the validation message, conflicted with a concurrent edit, or blocked behind another failed change. Each has its resolution path, walked through step by step in Working offline.
- A session that expired pauses sending without losing anything — sign in again and the queue resumes.
When you contact support or your administrator about a failed change, include the Ref: code from the row — it locates the same failure in the server logs.
I can't sign in
The distinction that matters is a fresh sign-in versus an existing session. An existing session survives offline: relaunching the app with no network keeps you signed in and working from device data. A fresh sign-in — after signing out, or on a new device — needs a connection, because your identity is verified by the server. So: if you signed out in the field with no coverage, you are locked out until you have network again, with your queued data safe but inaccessible until you sign back in.
Online and still failing? Try the web with the same credentials. If the web fails too, it is an account matter — password, account status, access — for your administrator, not an app problem. Sign-in itself is covered in Signing in to xMatix.
A tab or feature shows a cloud icon or says "Not available offline"
That surface needs the server right now, and the badge is the app saying so before you tap. Reports and Dashboards render server-side; the general attachments section, approval actions, Sense chat and a few lookup panels are in the same category. Nothing is broken — reconnect and they return. Everything without the badge keeps working from device data.
Data or layouts look stale
Fresh data and fresh configuration travel separately:
- Data — pull down to refresh the list you are looking at, or Sync now on the Sync Status screen for a full pass.
- Layouts, fields, labels, translations — these are metadata, refreshed in the background around syncs. To force it, use Refresh Metadata under Preferences → Data & Sync; it re-downloads entities, layouts and translations. This is the fix when your administrator says "I changed the form" and your phone still shows the old one.
- App behavior and branding — configuration is fetched at sign-in, app switch and foregrounding; background the app and return, or sign out and in, to pick up a just-published change.
The app warns about storage
Low device storage pauses offline downloads (the sync button renames itself to Sync changes — your outgoing changes still send) and shows a banner saying sync is limited. Three remedies, in order of effort: free device space outside the app; run Optimize database on the Storage & Database screen, which reclaims reclaimable space and says how much; and if your role does not need some record types offline, switch their rows to Manual or Off where your organization allows it. The Storage & Database screen's per-entity breakdown shows exactly what is taking the space.
A photo or file I added is missing on the server
Two different capture paths behave differently, and knowing which you used answers the question. Photos taken inside visit tasks queue offline — check the Sync Status screen for a File upload row still waiting or needing attention. Files added through a record's general attachments section upload directly and need a connection at the moment of upload — if it failed offline, the file was not queued; add it again while online. Details in Capturing data.
When to involve your administrator
Bring in an administrator when the cause is configuration or account-side: a record type outside the offline scope, a validation rule rejecting legitimate offline work, a missing capture widget or scanner, licensing (Sense), or sign-in failures that reproduce on the web. Give them three things: what the Sync Status screen shows, the Ref: code of any failed change, and the app version from Preferences → Advanced → Diagnostics — that combination usually turns a mystery into a lookup, since terminally failed changes also reach them as sync failure records.