Services and Maintenance Workflow

Overview

A service is any maintenance work on a machine — routine, repair, inspection, modification, or certification. One record type covers both the plan (upcoming work) and the evidence (completed work), moving through a single lifecycle: Upcoming → In progress → Completed, or Cancelled before completion.

Why a service exists: the three triggers

The defect-repair link closes the loop automatically: completing the service resolves its linked defect with a system note, unless a critical checklist item fails (below). See Defect Management Workflow.

Service-due detection

Machines carry service targets — next-service hours and/or a next-service date, advanced automatically each time a service completes. A daily scan compares every machine against its targets:

• Approaching (inside the warning window) notifies your managers — time to schedule.
• Overdue notifies again, at expired urgency.

Notifications are per service cycle, not per day — you're told once per approaching service, not nagged daily, and completing the service (which advances the targets) arms the next cycle. The Service Due report is the fleet-wide snapshot of the same signal.

An overdue service does not block the machine — service enforcement is advisory today, surfaced in the app and the console. The hard stop for an unsafe machine remains the defect out-of-service lockout.

Scheduling and assignment

Upcoming work is scheduled from the console — with a scheduled date, a due date, a priority, and an assignee. Assignment can be:

• Internal — a user, who's notified of the assignment.
• External — a workshop or contractor by name and reference, since your maintenance provider isn't a PreStartGo user. When the work comes back, one of your people records the completion on their behalf.

A service can also carry a service-type checklist template, so the work is performed against a defined list rather than free text.

Completing a service

Completion — from the console, or from the field — records the notes, the meter readings, and costs. Completion does real work beyond the status flip:

• The next service is forecast — hour and date targets advance by the machine's service intervals.
• Meter corrections apply — a captured hours/kilometres reading corrects the machine's counters, so telemetry accumulates on top of the verified reading rather than drifting past it.
• A linked defect auto-resolves (defect-repair trigger only — a service of another type that merely references a defect doesn't resolve it), unless a critical checklist item fails.
• People are told — completion notifies, and a webhook fires for integrated systems.

Mobile can log an already-completed service and transition existing ones — but scheduling upcoming work is deliberately console-only, so the plan stays in the office while the evidence comes from the field.

When a critical checklist item fails

A service with a checklist can't hide a safety fault. When a critical item is marked Fail, the service still completes with every answer kept, and then:

• On any service but a repair, the failed item gets a defect: the machine's open defect for that item if it already has one, which gets a comment naming the service, or else a new Critical defect whose description names the service.
• On a repair, the repair's own defect is not resolved. It stays open with a comment naming the service and the failed items. A failed critical item that the defect isn't about is handled as on any other service.
• Either way the machine is held. That defect takes the machine out of service: every pre-start on it fails until the defect is closed, exactly as after a pre-start's failed critical item. A Technician's own Out of Service lockout already on the defect stays theirs to lift.
• Your Administrators and Account Owner are told, so the fault doesn't wait for someone to read the service record.

A Fail on a non-critical item, or N/A on a critical one, changes nothing: a repair's defect resolves as usual. The console's Complete dialog warns you before you submit.

Cancelling

Upcoming or in-progress work can be cancelled with a reason (an office-role action). A cancelled service is terminal, and — unlike completion — resolves nothing: a linked defect stays open, which is exactly right for work that didn't happen.

Where to manage services

• Console → Services — every service in one table, with its status, priority, trigger, assignee, and scheduled and due dates; filter by any of those or by site, equipment and date range, open a row for that service's own page, and Export the filtered set.
• Equipment detail — the machine's own service history: who, when, readings, costs.
• Mobile — technicians find and complete orders on the machine's page; see Finding and Completing Service Orders.

Edge cases

• Hired-out machines — service records live with the machine's owner, keeping the maintenance record continuous across hires. A defect a critical checklist failure raises is the owner's too, and it's the owner's Administrators and Account Owner who are told.
• A service completed against a checklist carries the checklist evidence alongside the notes — useful where a certification needs the itemised record.
• Costs and invoices — estimated and actual cost, currency, and an invoice number ride on the record for the audit trail; PreStartGo doesn't process the payment itself.

Troubleshooting