Work order service tasks

What it does

Service tasks are the checklist a technician works through on site. You define reusable Service Task Types in settings, attach them to incident types or straight to a work order, and the technician marks each one off in the mobile app. Task durations roll up into the work order's estimated duration, and a task can carry an inspection.

Key facts

Two tables. Service Task Type (msdyn_servicetasktype) is the reusable definition; Work Order Service Task (msdyn_workorderservicetask) is the instance on a job.
Service Task Type fields are deliberately few: Name, Estimated Duration, Has Inspection, Description, plus notes.
On the work order instance you get msdyn_EstimatedDuration, msdyn_ActualDuration, and msdyn_PercentComplete (0–100, two decimal places). Percent Complete is the field the mobile app writes when the technician ticks a task.
msdyn_LineOrder controls sequence. Set it deliberately on the incident type, because that ordering is what the technician sees as their process steps.
Task durations sum up into the incident type's estimated duration, together with service durations. Once tasks have durations, the incident type's estimated duration can no longer be set manually.
A work order service task links to msdyn_WorkOrder, optionally to msdyn_WorkOrderIncident, msdyn_Booking, msdyn_CustomerAsset and msdyn_AgreementBookingServiceTask. That asset link is how per-asset task history gets built.
Inspections attach here: msdyn_Inspection points at the inspection template, msdyn_InspectionEnabled is the flag, and results land in msdyn_InspectionResult (Pass / Fail / Invalid) and msdyn_inspectiontaskresult (Pass / Fail / Partial Success / NA).
Service tasks are not billable in themselves. They carry no price and no line status. Billing comes from work order services, which are a different table entirely.
Tasks can be added to a work order manually as well as through an incident type, and the technician can add them on site if their security role allows.

When to use / skip

Use them wherever the client has a documented procedure and cares whether it was followed. Regulated work, safety checks, warranty claims, anything where "did they actually do step four" is a question someone will ask — that's a service task.

Skip them where the work is genuinely diagnostic and unstructured. A break-fix call-out where the technician's whole job is to work out what's wrong doesn't benefit from a three-item checklist that says "attend, diagnose, fix". You get compliance theatre and technicians ticking everything at once in the van.

The other honest reason to go light is time. Every task is a tap in the mobile app. Load a two-hour job with thirty tasks and technicians will find a way around them, usually by completing them all at the end, which destroys the data you built them for.

Configuration decisions

Which procedures become service tasks, and whether tasks live on the incident type (the normal answer) or get added ad hoc.
Whether tasks carry estimated durations. Doing so gives you duration roll-up but takes manual duration control away from the incident type — decide which you want.
Where the line between a service task and an inspection sits. Tasks record that something was done; inspections capture structured answers. A yes/no with a photo is an inspection, not a task.
Whether percent complete is treated as binary (0 or 100) or genuinely partial, and whether any process depends on it.
Whether technicians may add or delete tasks on site, which is a security role decision as much as a process one.
Whether tasks need to be linked to customer assets for per-asset history, which affects how you structure incident types on multi-asset visits.

Gotchas

Tasks copied from an incident type only appear if the user creating the work order holds Create privilege on the work order service task table. Missing privilege gives you a work order with products but no tasks and no error.
Adding durations to tasks after go-live silently changes the incident type's estimated duration and, with it, the length of every new booking. Schedule board slots shift and nobody connects the two.
Service tasks don't bill. Clients repeatedly assume that adding a two-hour task charges for two hours; it doesn't — you need a work order service line.
Line order is easy to forget on the incident type, and the default ordering the technician then sees can be effectively random.
Changing a service task type's name or duration doesn't touch tasks already sitting on open work orders. You get a mixed population for as long as those jobs stay open.
Deleting a work order incident to change the incident type takes its service tasks with it, including any partially completed ones.

Consultant notes

Ask to see the client's existing paper job sheet in the first workshop. That document is the service task list, and it's usually already been argued over internally.
Demo the mobile app view of tasks, not the web form. The web form makes tasks look trivial; the mobile experience is what determines whether technicians actually use them.
Push back on long checklists. Suggest a target of under ten tasks per incident type and make the client justify anything longer.
Before go-live, test a full incident type end to end on a real device: tasks appear, order is right, durations roll up, inspection opens. It fails often enough to be worth the ten minutes.
Tell the client who owns the task library after handover. Like incident types, it's configuration that needs a named owner or it drifts.

Worth another look if inspections change how they attach to tasks, or if percent complete gains richer behaviour in mobile.