What it does

Work order type is the broad category of job — installation, inspection, preventative maintenance, warranty repair. It is a required lookup on every work order, it can force a price list onto the work order, it can make an incident type mandatory, and it sets the default taxable flag. Small table, disproportionate effect.

Key facts

• The table is msdyn_workordertype. It is a genuinely thin entity: name, price list, incident required, taxable, plus the usual ownership and state columns.
• msdyn_pricelist is a lookup to pricelevel and is described as the default price list for work orders of this type. If it's set, it wins over the account's price list on new work orders.
• msdyn_incidentrequired is a Boolean defaulting to false. Set it true and a work order of this type cannot be saved without an incident type.
• msdyn_taxable is a Boolean defaulting to true on the work order type, while msdyn_taxable on the work order itself defaults to false. Worth knowing if you're scripting data loads.
• Work order type is required on the work order. There is no "no type" state, so you will be creating at least one on day one.
• Incident types carry a Default Work Order Type, so the incident type can set the work order type rather than the other way round. Whichever direction you choose, pick one and be consistent.
• Work order type is the main axis for views, charts, dashboards and Resource Scheduling Optimization scope filters. It is also what most clients want on the schedule board booking template.
• Deactivating a work order type leaves historical work orders pointing at it. It stops appearing in the picker but existing records are unaffected.

When to use / skip

Not optional, so the decision is only about the list. Keep it short. Six to a dozen types is normal; if you're heading past twenty you have almost certainly started modelling incident types in the wrong table.

The test is whether the distinction matters to the business, not the technician. Reporting cuts, billing behaviour, RSO scope, who gets the job — those justify a type. "Boiler service" versus "boiler repair" is usually incident-type territory. "Chargeable" versus "warranty" is usually a work order type, because it changes the price list and the taxable default.

If a client asks for work order types that vary by region or business unit, resist. That's a business unit or a custom field; putting it in the type multiplies the list and ruins every chart.

Configuration decisions

• The list itself, and specifically whether billing model (chargeable, warranty, contract, goodwill) is expressed as work order type or as something else.
• Whether each type carries a price list, and how that interacts with account-level price lists and agreement price lists. Decide the precedence you want and test it.
• Which types require an incident. Maintenance and inspection types usually should; ad-hoc reactive types often shouldn't, because the dispatcher doesn't yet know what's wrong.
• The default taxable value per type, and whether tax is being handled in Dynamics at all or deferred to an ERP.
• Whether work order type is set by the user or inherited from the incident type's Default Work Order Type. Two routes to the same field is a recipe for arguments.
• Whether RSO schedules, schedule board filters and SLA rules will key off work order type — because that decides how stable the list needs to be.

Gotchas

• Price list precedence is where most of the pain sits. Work order type, service account, agreement and entitlements can all have opinions. Changing the work order type on a saved work order may repoint the price list and leave existing product lines priced from the old one.
• Incident Required set to true after go-live breaks any existing automation, integration or Power Automate flow that creates work orders without an incident. Failures show up as save errors in a background flow no one is watching.
• The taxable default on the work order type does not retro-apply. Change it and only new work orders pick it up.
• Renaming a work order type is fine functionally, but it silently invalidates any hard-coded name filters in Power BI, flows or JavaScript. Prefer to deactivate and create new when the meaning genuinely changes.
• Both work order type and incident type default each other in different directions depending on entry order. Users who pick the incident type first can see the work order type change under them.
• Client-side scripts on the legacy work order form that assumed particular work order type names are a common upgrade casualty when moving to the current work order experience.

Consultant notes

• Get the list agreed in the first design workshop and stop revisiting it. It's the cheapest configuration in the system and the one that most affects how the client's reports look at the end.
• Demonstrate the price list precedence explicitly with a work order that has an agreement, an account price list and a typed price list all in play. Clients assume it's obvious; it isn't.
• Push back on using work order type for anything with more than about fifteen values. Offer a category field.
• Before go-live, check every integration and flow that creates work orders still passes a work order type, and check Incident Required on each type against what those callers actually send.
• Tell the client that this table is admin-owned configuration, not user data. Left open to power users it grows without control.

---

Worth another look if price list resolution or the entitlement pricing behaviour changes.