Products and services on a work order

What it does

Work order products are the parts consumed on a job, priced by quantity. Work order services are the labour, priced by duration. Both come from the same Dataverse product catalogue that Sales uses, both carry an estimated and a used state, and both are what the invoice is built from when the work order is posted.

Key facts

Every product record needs a Field Service Product Type: Inventory, Non-inventory, or Service. Inventory affects warehouse stock; Non-inventory doesn't; Service is measured in time.
Work order products (msdyn_workorderproduct) have msdyn_LineStatus with two values only: Estimated (690970000) and Used (690970001). The technician flips it to Used and enters actual quantity.
Three quantity fields, and they are not the same thing: msdyn_EstimateQuantity, msdyn_Quantity (actual), and msdyn_QtyToBill (defaults to Quantity but can be overridden). Only Quantity to Bill drives the invoice.
Services follow the same shape with duration instead of quantity — estimate duration, duration, and duration to bill.
msdyn_Allocated is a Boolean, default false, reserving inventory before use. Auto Allocate Estimated Products in Field Service Settings turns this on automatically and ships disabled.
Use of Products out of Stock in Field Service Settings is either Restrict (block use at zero inventory) or Confirm (warn only).
Price comes from msdyn_PriceList, which is required on the product line. msdyn_UnitAmount can be overridden per line. msdyn_TotalCost is unit cost times quantity plus additional and commission costs.
Convert to Customer Asset on the product record is what turns a used product into a customer asset — and it fires when the work order system status reaches Completed, not Posted.
Product lines can be linked to msdyn_WorkOrderIncident, msdyn_Booking, msdyn_CustomerAsset and msdyn_Entitlement, which is how per-incident and per-asset cost reporting is built.
Products must be in Active (published) state and present on the work order's price list to copy across from an incident type.
Keep work order child records — products, services, tasks, incidents — under about 500 per work order. Beyond that Microsoft warns about timeouts, particularly on agreement generation.

When to use / skip

Product lines aren't optional if the client bills for parts or tracks van stock. The genuine decision is whether to run Field Service inventory at all.

Full inventory — warehouses per van, allocation, transfers, purchase orders, adjustments — is a real project inside the project. It is worth it where parts are expensive, traceable, or where stock accuracy drives purchasing. It is not worth it where technicians carry a boot full of consumables worth forty quid and the client just wants them on the invoice. In that case, mark everything Non-inventory, bill it, and don't pretend to track stock you were never going to count.

The usual middle ground works well: Inventory for the expensive, serialised, chargeable items; Non-inventory for consumables. Decide this per product category, in a workshop, with whoever owns stock.

Configuration decisions

Field Service Product Type per product, and specifically which categories are genuinely tracked as inventory versus written off as consumables.
Whether to enable Auto Allocate Estimated Products, and therefore whether estimates hold stock.
Restrict versus Confirm for out-of-stock use — a policy question about whether a technician can fit a part the system says doesn't exist.
Which products set Convert to Customer Asset, which is the foundation of asset history and hard to backfill later.
Price list structure: one list, list per customer segment, or agreement-specific lists, and how entitlements adjust pricing on top.
Whether Quantity to Bill can differ from Quantity, and who is allowed to change it — this is the goodwill and warranty adjustment mechanism.
Whether unit price overrides on the line are permitted at all, or locked down to protect margin.

Gotchas

A product missing from the work order's price list won't copy from the incident type and won't be selectable. Silent, and by far the most common support call.
Unit group and default unit mismatches between the product and the price list produce pricing that looks plausible and is wrong. Check units before checking anything else.
Convert to Customer Asset firing at Completed, not Posted, surprises people who expect assets to appear after invoicing.
Line Status left at Estimated means the line does not reach the invoice. Technicians who fit the part but never change the status produce work orders that bill nothing, and nobody notices until the month-end reconciliation.
Quantity to Bill defaults from Quantity, so editing Quantity after Quantity to Bill has been touched leaves them out of step with no warning.
Deactivating a work order leaves its product and service lines active. They stay in reports and, in some configurations, in inventory allocation.
Agreement-generated work orders with large product sets are the usual cause of generation timeouts. Keep the child record count sensible.

Consultant notes

Run a pricing walkthrough with the finance stakeholder before build: one product, through price list, entitlement and agreement, to the invoice. It exposes assumptions that design workshops never do.
Demo the estimate-to-used transition on mobile. That single interaction is where invoice accuracy is won or lost, and it should be the shortest possible journey for the technician.
Push back on full inventory unless the client has someone who will actually own stock accuracy. Half-implemented inventory is worse than none.
Before go-live, post a test work order end to end and check the invoice line by line against what the technician entered — quantities, units, tax, price list.
Tell the client that Quantity to Bill is their goodwill lever, and agree who is allowed to use it. Undefined, it becomes an unmonitored discount.

Worth revisiting if the inventory or entitlement pricing behaviour shifts, or if finance and operations integration changes how lines are billed.