Attaching inspections to service task types and work orders

What it does

An inspection template never attaches to a work order directly. It attaches to a Service Task Type, and that task type is what lands on the work order — manually by a dispatcher, or automatically because it sits on an incident type. The technician then opens the work order service task and answers the inspection there.

Key facts

Service task types are set up under Settings > Work Orders > Service Task Types. The fields that matter are Name, Estimated Duration, Description and Has Inspection.
Has Inspection is set to Yes when the task type is linked to an inspection template. It is the flag the rest of the system keys off.
Publishing a template offers "Publish and generate a new service task type", which creates the task type and wires it up in one step. The alternative is publishing and then associating the template to an existing task type by hand.
Estimated Duration on the task type rolls up into the work order's duration, which then feeds the schedule board. An inspection with no duration set silently contributes nothing to the estimate.
Service task types can be attached to incident types, so adding the incident type to a work order brings the inspection along automatically. This is the pattern you want for anything routine.
The work order service task record (msdyn_workorderservicetask) carries msdyn_inspectiondefinitionid — a lookup to the specific template version, not to the template. The version is stamped at the point the task is created.
The work order must be saved before the inspection is available on a newly added task. On an unsaved work order the task shows but the inspection does not render.
Completion is two things, not one: saving the inspection answers, and marking the task complete with a Result of Pass, Fail, Partial Success or NA plus an actual duration.
One inspection response per work order service task. If two inspections are needed, that's two task types on the work order.
Inspections can also be created straight against a customer asset with no work order, using the msdyn_inspectioninstance table, but that route needs a relationship display option changed by hand and is not available in the mobile offline profile.

When to use / skip

Bind through incident types wherever the work is standardised. The dispatcher picks one incident type, the correct tasks and inspections arrive, and nobody has to remember that the annual gas safety check needs three particular forms. This is the whole point of the incident type model and inspections fit it cleanly.

Add task types manually only for genuinely ad-hoc work, or during a pilot when the incident type catalogue isn't settled yet. If you find dispatchers routinely hand-adding the same inspection to the same kind of job, that's a missing incident type, not a training problem.

Avoid the standalone customer-asset route unless the requirement is specifically an inspection with no job behind it — a warehouse stock condition check, a pre-sales survey. It lacks offline support and the PDF export behaviour that work order inspections get, so it is a narrower tool than it first appears.

Configuration decisions

Which inspections belong on incident types versus which stay dispatcher-added, and therefore how granular the incident type catalogue needs to be.
Whether to let the publish action generate a service task type or to create task types deliberately by hand — generated ones inherit the template name and land in the same flat list as everything else.
Estimated Duration for every inspection task type, agreed with the operations lead, because it directly affects booking length on the board.
Whether the inspection should be related to a customer asset via Service Task Relates To, which is what builds a usable asset service history.
Task ordering on the work order, if the client cares that the safety inspection is done before the work rather than at the end.
Whether any inspection needs to exist outside a work order at all, and if so whether losing offline support is acceptable.

Gotchas

Because the work order service task pins a specific template version, tasks created before a republish keep the old questions forever. Two technicians on the same job type in the same week can legitimately see different forms.
Relating work order incident types to customer assets automatically associates the related service tasks with those assets — helpful when you want it, confusing when you didn't know it was happening.
Dispatchers adding a task to an unsaved work order and finding no inspection is the single most common "it's broken" ticket in the first month. It isn't broken, they just need to save first.
Deleting a service task type that's referenced by historical work order service tasks is not something to do casually. Deactivate instead.
Estimated Duration left at zero on inspection task types quietly under-books every job that includes them, and the symptom shows up as technicians running late rather than as anything obviously inspection-related.
The Field Service - Dispatcher role can add tasks and read responses; only Field Service - Administrator can create templates and associate them to task types. Clients who expect team leaders to maintain forms need a role conversation.

Consultant notes

Map inspections onto the incident type catalogue in the same workshop where you design incident types. Doing it afterwards means reopening every incident type record.
Tell the client explicitly that changing a form does not change forms already on scheduled work. Say it once at design time and again at go-live; it prevents a genuinely awkward conversation later.
Demo the dispatcher path — incident type on, tasks appear, technician sees the form — rather than the admin designer. It's the flow the client will actually run every day.
Before go-live, check that every inspection task type has a sensible Estimated Duration and that the schedule board reflects it. It's a five-minute check that avoids weeks of capacity noise.

Worth another look if standalone asset inspections gain offline support, which would change the "use a work order" default here.