Native screen evidence
The mobile app is a separate React Native product surface. A web entity form squeezed to phone width does not prove the native form, local outbox or device-only controls, so this overview deliberately has no screenshot until an authenticated demo2 mobile-build capture is available. Use the named controls in the procedures below as the source of truth; web Setup screenshots appear only on the administrator pages where the web UI is the actual product being described.
Before a field day, open assigned records while connected, confirm required lookups and reference data are present, and check the last successful sync. After saving, use Sync Status to distinguish local persistence from server confirmation and resolve any item marked Needs attention.
The xMatix mobile app puts your organization's apps, lists and records on a phone or tablet, built offline-first so field work continues through dead zones and syncs when coverage returns. It is provided by your organization — your administrator tells you how to install it — and it signs in with the same account and permissions you use on the web. This section goes deeper than the onboarding material: the screens, the sync machinery you can see and act on, and the configuration behind it all.
If you are new to the app, start with Using xMatix on mobile for installing, signing in and the first sync, and How offline-first mobile works for the offline model — local data, the outbox, and how conflicts are handled. The pages here assume that foundation and build on it.
What's in this section
| Page | What it covers |
|---|---|
| How the mobile app is organized | Tabs, the app drawer, lists and records — and why the shape of the app is your organization's configuration |
| Working offline: sync status and recovery | The Sync Status screen in depth — pending changes, fixing rejected edits, conflicts, and the Storage & Database screen |
| Capturing data in the field | Forms, photos and attachments, signatures, and barcode scanning where your organization has configured them |
| Approvals on mobile | The approval panel on a record — submit, approve, reject, reassign, recall, and the request history |
| Sense on mobile | The Sense Agent chat screen — what it can do on a phone and how access is granted |
| Location tracking | Organization-controlled location capture during check-in sessions — what is recorded, when, and how it stays visible to you |
| Configuring the mobile app | For administrators: mobile layouts, app pages, branding, offline policy and the rest of the Mobile App record in web Setup |
| Monitoring sync failures | For administrators: the records devices file when a queued change fails for good, and how to triage them |
| Troubleshooting | Symptom-first help — missing records, stuck changes, sign-in, stale data, storage warnings |
One account, one set of permissions
Nothing in the mobile app runs on a separate identity. You sign in with your work account, and entity, field and record-level security apply exactly as they do in the browser — the app stores and shows only what you are allowed to see. What differs on mobile is presentation (layouts designed for a phone) and availability (a configured subset of data is kept on the device for offline use). When a record you can open on the web is absent on the phone, the cause is almost always the offline scope, not your access — Troubleshooting walks through how to tell.
Users and administrators
The first six pages are written for people using the app day to day. The two administrator pages cover the other side: everything that shapes the app — which tabs exist, which entities work offline and for how far back, branding, check-in gates, update channels — is authored in web Setup and versioned out to devices, with no app-store release needed for configuration changes. If the app looks different from this documentation, that is usually configuration, and the configuration reference explains which lever is involved.