Work order incident types

What it does

An incident type is a template for a specific job. Add one to a work order and it copies in the service tasks, products, services and characteristics that job needs, and sets the estimated duration. It is the single most important configuration object in Field Service and the one clients under-invest in.

Key facts

Incident types describe a specific request — an error code, a complaint, a named procedure. Work order types describe a broad category. They are not interchangeable and both exist on the work order.
Adding an incident type to a work order creates a Work Order Incident (msdyn_workorderincident) record, which then spawns Work Order Incident Products, Services, Service Tasks and Characteristics as child records copied from the template.
One work order incident is flagged primary via the Boolean msdyn_IsPrimary — either the first one added, or the one matching the work order's Primary Incident Type field. Useful for business logic and reporting.
Estimated duration on the incident type is the sum of related service task durations plus service durations. If service tasks with durations exist, you can't set it by hand.
Default Work Order Type on the incident type sets the work order type, and can bring a price list with it.
Copy Incident Items to Agreement controls whether the incident's items are snapshotted into an agreement at activation (Yes) or resolved live from the current incident type definition (No). This is a genuine behavioural fork, not a cosmetic setting.
Characteristics on an incident type feed scheduling. Add multiple incident types and the scheduler looks for a single resource holding all the combined characteristics.
If you're using requirement group templates for multi-resource work, put characteristics on the requirement group template, not the incident type — and note only one incident is allowed per work order when requirement groups are in play.
Auto-population needs the products to be Active, the work order's price list to contain every product and service on the template, and the user to hold Create privilege on the work order product, service and service task tables. Any one of those missing and items silently don't appear.
Changing the incident type on an existing work order means deleting the Work Order Incident and creating a new one. There is no swap in place.

When to use / skip

Everyone uses incident types. The question is how many and how granular.

The failure mode at one extreme is a single "General repair" incident type that carries nothing, in which case you have built a work order system with no templates and technicians type everything. At the other extreme is a client who models 400 incident types because their legacy system had 400 fault codes, most of which differ only in the description. That's a maintenance problem forever, and the picker becomes unusable.

The workable line is: create an incident type where the work genuinely differs — different tasks, different parts, different duration, different skills. Where only the reported symptom differs, use one incident type and capture the symptom on the work order or in a related case. Aim for tens, not hundreds, and be willing to add more after go-live once real data shows what's actually being booked.

Configuration decisions

Granularity: how many incident types, and what distinguishes one from another. Settle this before anyone starts data entry.
Whether incident types carry a default work order type, and therefore an implied price list, or whether the work order type is chosen independently.
Whether estimated duration is derived from service tasks and services, or whether you deliberately leave tasks duration-free so someone can set the duration directly.
Characteristics and skill levels per incident type — including whether to leave the rating value blank to accept any proficiency, which is often what you actually want.
Whether agreements snapshot incident items (Copy Incident Items to Agreement = Yes) for contractual stability, or track the live definition so procedure changes propagate.
Whether multiple incidents on one work order is a supported pattern for this client, or whether each incident gets its own work order for asset and billing traceability.

Gotchas

Products missing from the work order's price list simply don't copy across. No error, no warning — the technician just doesn't see the part. This is the most common "incident types aren't working" ticket.
Multiple incident types on one work order means the schedule assistant hunts for one person with every characteristic. On a mixed electrical-and-mechanical job you will get zero results and no explanation.
Copy Incident Items to Agreement = Yes means later corrections to the incident type never reach existing agreements. Clients discover this two years in, when a safety step was added and none of the contracted jobs include it.
Estimated duration goes read-only once service tasks carry durations. People add a task, lose the ability to override duration, and can't work out why.
Deleting a Work Order Incident to change type also removes its copied products, services and tasks — including any quantities the technician had already adjusted.
Security is a silent failure path here. A user without Create on work order service task gets a work order with products but no tasks and no error message.

Consultant notes

Build three or four real incident types with the client's own parts and tasks in the first workshop, then demo creating a work order from one. It is the fastest way to get a client to understand the whole data model.
Insist that the price list conversation happens alongside incident type design, not after. They are the same conversation whether or not the client thinks so.
Push back on one-incident-type-per-fault-code. Offer a fault code field or a case as the alternative and make the maintenance cost explicit.
Check before go-live that every product and service referenced by every incident type appears on every price list a work order might use. A quick FetchXML comparison beats finding out in the field.
Warn the client that incident types are living configuration and someone on their side must own them after handover. Unowned, they rot within a year.

Worth revisiting if requirement groups or the resolution suggestion behaviour change how characteristics are handled.