The xMatix mobile app is built offline-first: the data your work needs is kept on the device, screens read from that local copy, and edits made without a network wait in an outbox until connectivity returns. There is no separate "offline mode" to switch into — connectivity is just a state the app tracks. When the network drops mid-visit, you keep browsing and editing the same screens; when it returns, queued changes sync in the background. The design goal is that a field day with patchy coverage looks, from the user's side, like a normal day.
Before field work, open the assigned record while connected and confirm the required lookups and reference data are available. After editing, use the app's sync status and pending-changes view to distinguish a locally saved item from a server-confirmed one; never assume that tapping Save proves upload.
What lives on your device
The app keeps a local copy of the data your role works with: reference data such as customers, products, price lists and picklists, plus a recent window of transactions — recent documents, records assigned to you, and anything with pending local edits. Form layouts and settings are cached too, so records open and forms render without a network. Which record types are available offline, and how much history is kept, follows your organization's sync configuration, so an administrator can widen or narrow the offline footprint per entity rather than syncing everything to every phone.
Edits queue in an outbox
Every save on mobile goes through a durable outbox on the device. Online, a queued change is sent immediately and you barely notice the queue exists; offline, it simply waits. Queued changes are kept until they sync — they survive closing the app, restarting the phone, and even your session expiring, in which case sending pauses until you sign in again rather than anything being dropped. Each queued change also carries its own identity, which the server uses to recognize a resend: if the app retries after an interrupted connection, the change is applied once, not twice.
Sync status is visible
You should never have to guess whether your work has reached the server. The app shows connection state and last-synced time, and a pending changes screen lists every queued edit with its status: waiting to send, sent, or needs attention. If the server rejects a change — a validation rule failed, for instance — the item is marked failed with the reason attached; you can open it, fix the field the server complained about, and resubmit, or discard it deliberately. Failed items stay on the device until you act on them, so a rejection is something you resolve, not something that silently vanishes.
Conflicts are resolved, not silently lost
If a record you edited offline was also changed on the server in the meantime, the app does not blindly overwrite either side. The sync detects that the record moved underneath your edit and parks your change as a conflict, and you choose how to proceed — keep your version or discard it in favor of the server's. The mechanism matters more than the label: your queued edit is preserved through the conflict, so whichever way you decide, the decision is yours and made with both versions on the table rather than by whichever device happened to sync last.
Long stretches offline
The model holds over days, not just minutes. Cached data remains readable and editable however long you are disconnected, and the outbox keeps accumulating. Two things are worth knowing about extended gaps: an expired sign-in pauses syncing but never discards local work, and after a very long gap the app refreshes its local data in full on reconnection — the reliable way to catch deletions and permission changes that happened while it was away.
Common questions
What happens if I close the app before my changes sync?
Nothing is lost. Queued changes live in the outbox on the device, not in the app's running memory, so they survive the app being closed, the phone restarting, or the battery dying. The next time the app runs with connectivity, the queue resumes sending from where it left off. Each change's identity ensures a resend after an interruption is applied exactly once, so you can close the app mid-sync without creating duplicates.
What if someone edited the same record while I was offline?
The app detects it at sync time: your change is parked as a conflict instead of being applied over theirs. You will see it flagged on the pending changes screen with both facts visible — your edit, and that the server version moved — and you decide whether to keep your version or discard it. Neither your edit nor theirs is silently overwritten; the queued change is preserved until you make the call.
My session expired while I was offline — is my queued work gone?
No. Authentication and your local data are deliberately independent: an expired session pauses sending, nothing more. You can keep reading cached records and keep queueing edits while signed out of the server's view; when you next sign in, the outbox resumes and everything queued goes up in order. Signing out explicitly asks before touching local data, so even a deliberate logout does not quietly take your pending work with it.
Why can't my colleague see the record I just created?
Because it has not synced yet. A record created offline exists on your device the moment you save it, but it reaches your colleagues only after your outbox sends it and their apps pull the update. Check the pending changes screen: if the item is still waiting or has failed validation, that is the reason. Once it shows as sent, it is on the server and visible to everyone with access.