The technician's day runs in the xMatix mobile app. Its lists and forms are metadata-driven, so what a given organization's technician sees is the layout its administrator configured; this page describes the platform behaviour underneath — what synchronizes offline, what needs the server, and where work time is actually recorded — without claiming a particular screen.
Before leaving coverage
Synchronize while online and confirm the device holds the jobs expected for the day. Open each job rather than trusting the list title and check its customer or site, address, asset, planned time, instructions, parts and any checklist or evidence requirement. If a dispatcher has reassigned or rescheduled work, synchronize again before travelling.
Service orders reach a technician through explicit ownership, a dispatch console assignment, a visit plan or another configured process. They are not assigned by the Partner Resource rules — those run only on Lead, Opportunity and Product Demo inserts (see Automatic owner assignment) — so a missing service order is a dispatch question, not a rule question.
Check-in and the working session
Where attendance is enabled, check-in starts the working session and check-out ends it. Punches are recorded against the technician's own resource and can be captured offline: the app keeps a dedicated punch queue and replays it in order when the network returns, marking replayed punches as taken offline. Pause is available when the organization allows it; it freezes the session timer and stops location capture on the device, but there is no server-side pause punch — the session keeps its single check-in.
If the organization has enabled location tracking, the app asks for background ("Always") location permission and blocks check-in until it is granted; there is no foreground-only fallback. Location points are uploaded in batches and may carry the check-in they belong to, but the server accepts a batch without one, so administrators correlating a travelled path with attendance should match on resource and time rather than on that link alone.
Work execution: the time sheet
Work time is recorded on the service order time sheet, not on the service order header:
- On the service order, Create Time Sheet creates one time sheet with a line per selected Work Item order line (parts lines are skipped) and stamps the technician from the order.
- On the time sheet, tick the lines being worked and use Start. Starting stamps the server's clock as the work start; a date cannot be supplied from the device.
- Pause closes the current segment and requires a Pause Reason when the work is set to Paused.
- There is no separate Resume: Start again opens a new segment on the same line and marks the previous one as superseded; paused time is the gap between segments.
- End closes the line. A line that has ended cannot be started again, and a line that is running cannot be started twice.
Each stage re-derives the sheet header and the parent service order's Is Work Started, Is Work Paused and Is Work Ended flags from all of the sheet's lines, so the order shows work ended only when every line has ended. Bay allocation (Get Bay Candidates, Allocate Bays) also runs from the time sheet where the workshop uses bays.
These actions are online-only. The mobile app sends server actions directly and refreshes the record afterwards; unlike record edits, they are not queued for later replay. If connectivity is unavailable when a stage must be recorded, keep the job open, note the actual time by local procedure, and run the action once connected — the timestamp will be the server's time at that moment, so escalate rather than backfilling an invented start.
Checklist results, parts and customer evidence belong to the service order or visit the organization configured; confirm the correct line or task before entering them, especially when one order carries several operations.
What works offline
Record creates, edits, deletes and file uploads made in the app are stored locally and forwarded when the network returns, with a Pending changes screen showing what is queued, in flight, retrying, or rejected by the server. Attendance punches use their own queue as described above. Server actions — the time-sheet stages, bay allocation and any other action button — need a live connection. A local edit is not complete until synchronization and a subsequent refresh show the server's version.
End-of-day reconciliation
Before check-out:
- Reconnect and synchronize; clear anything rejected on the Pending changes screen against the source record rather than by re-creating it.
- Reopen each completed job and verify the time sheet's segments, pause reasons, work status, parts, checklist completion and evidence.
- Confirm no time-sheet line is still running.
- Check out and verify the attendance session closed.
If the device was offline during work, compare the recorded timestamps with the actual chronology and escalate missing stages instead of inventing times.
Common questions
Is every service action offline-safe?
No. Record edits and uploads are; server actions — including the time-sheet Start, Pause and End — are not. Treat them as online-dependent unless the exact deployed form has been tested otherwise.
Where is "Resume"?
Use Start again on the paused line. It opens a new work segment; the paused interval is computed as the gap between the two segments.
Do Start and End create the time sheet?
No. Create Time Sheet on the service order creates it (one line per Work Item line). Start, Pause and End then move the selected lines through their stages; the order's work flags follow the lines.
Can queue-routed work be declined?
An offered routing item can be declined and is re-routed to someone else. Work a dispatcher assigned directly is not an offer and has no decline; coordinate reassignment with dispatch. Note that a decline re-route drops the original required skill, as described in Skills, capacity and work routing.