xMatix Service runs the service operation around the assets you maintain: the service order is the working document — parts and labour on one job card — and around it sit estimates, invoicing, time sheets, inspection checklists, service recommendations, campaigns that generate the work, and the asset service contracts that decide who pays for it. This page maps the module and links every topic in this section.
Read the workspace
- 1
The Service app's navigation; administrators decide which entities and app pages appear here, so your tenant's bar may differ.
- 2
All Service Orders is the active view; the drop-down switches to other saved views and the recent chips reopen the last job cards.
- 3
Summary tiles count orders in each lifecycle stage — a quick read of workshop load before filtering.
- 4
Document Number, Document Date, Partner Account and Branch identify the job card and the workshop that owns it.
- 5
Account and Asset say whose unit is on the job; Status (Draft, Work To Start, Work In Progress, Work Paused, Work Completed) says where it sits.
- 6
Search, column filters and refresh narrow the register without changing any record.
Start in All Service Orders, the populated operational register rather than a blank create form. The summary tiles above the table count the orders in each lifecycle stage; the active view and record count define the population you are reviewing; search and column filters then narrow it by document, customer, asset, status or owner. Each row keeps identity, customer, asset and lifecycle evidence together, so open the exact job card from this list before changing work, allocation or billing state.
The list is the entry point, not the whole record. After opening a row, the saved service-order page separates Lines, Complaints, Details, Related (time sheets, estimates, invoices and other linked documents) and Recommendations into their own tabs, with the amounts panel and the asset service contract card alongside. Use the service-order lifecycle guide for the fields and the evidence to check on a populated record.
The Service app
The Service app appears in your navigation when your administrator has granted it. Its shipped entries are:
| Entry | What it holds |
|---|---|
| Lead | Service leads, including the reminder leads campaigns generate |
| Opportunity | Service opportunities — the request stage before an order |
| Quote | Service estimates, including those generated from service orders |
| Service Order | The job card: lines, actions and the full lifecycle |
| Invoice | Invoices generated from service orders |
| Service Campaign | Campaigns, their members, rules and processing actions |
Administrators can rearrange this navigation — add app pages such as the Allocation Console, Transfer Members or Execute Campaign, or move entities in and out — so the bar in your tenant (and in the demo screenshots) may differ from the shipped list. Neighbouring apps complete the picture: the Contracts app holds the contract records module (contracts, contract lines, terms, SLAs and PM tasks), and the Service Settings App holds service bays and, in some configurations, call records. Time sheets, asset service contracts and service recommendations belong to no app entry — they are reached from the service order or asset they belong to, or directly by their entity list. Which apps and entities you see is decided by your license and security profile, and administrators can place any of these entities in other apps' navigation.
Section map
| Page | What it covers |
|---|---|
| The service order lifecycle | Where orders come from, the status flow, parts vs labour, delivery |
| Invoicing | Full and selective invoicing, pending quantities, document splitting and claim routing |
| Recording labour with time sheets | Time sheets per order, work start/pause/end, roll-up to the order |
| Checklists on service orders | Populating template-driven checklists and completing them |
| Service recommendations | Per-asset advisories: where they come from, accepting and posting them |
| Running service campaigns | Members, rules, and the processing actions that generate work |
| Asset service contracts | Per-asset entitlements and how they gate and route service work |
| Contract records | The Contracts app: contract, line, term, SLA and PM task records |
| Managing contract records | Creating and maintaining contract records |
| Service configuration | The module switch, service bays, and the masters the module reads |
| Troubleshooting | The refusals service users actually hit, and what each one means |
Where the boundaries are
Three related areas are documented elsewhere. Dispatch — the allocation console, crew scheduling and skills-based routing — belongs to Field Service. Support cases and case SLAs — queues, entitlement enforcement and response timers — belong to Support. And because service orders reuse the platform's commercial machinery, pricing, invoicing detail and claims are shared with Sales.
Common questions
How does Service relate to Field Service?
Service is the document layer: orders, estimates, invoices, contracts and the workshop flow around an asset. Field Service is the execution layer for crews in the field — dispatch boards, scheduling and skills-based routing — described in its own section. A field job and a workshop job can end in the same service order; what differs is how the work gets assigned.
Where do support cases live?
In the Support section. Cases, queues and SLA timers are a separate flow from service orders — a case may lead to a service order when physical work is needed, but case handling itself is documented there.
Do service orders have their own pricing and invoicing rules?
No — they reuse the sales machinery. Prices come from price lists and discount groups, taxes from tax groups, and invoices land in the same invoice list as sales invoices. See Pricing, discounts and taxes and Invoicing and payments; what is Service-specific — posting types that route work to claims instead of invoices — is covered under asset service contracts.