Warehouses, truck stock and inventory journals

What it does

Field Service tracks parts as Product Inventory rows sitting in Warehouses. A warehouse is any stocking point — a depot, a stores cage, or a technician's van — and work order product lines move stock in and out of it. Every movement writes an inventory journal, which is the ledger you reconcile against.

Key facts

Four quantities are held per product per warehouse: Quantity Available, Quantity Allocated, Quantity on Hand (available plus allocated) and Quantity on Order.
Only products with Field Service Product Type set to Inventory are tracked. Non-inventory and service products move no stock, ever.
You can't type a quantity onto a product inventory record. Numbers only change through adjustments, transfers, purchase order receipts, RMA receipts, work order usage or manual journals.
A work order product with line status Estimated and Allocated = Yes increases Quantity Allocated and reduces Quantity Available. Setting line status to Used decrements Quantity on Hand and writes a journal.
The warehouse on a work order product defaults from the bookable resource assigned to the booking, which is how van stock works. No warehouse on the resource means no deduction.
Inventory adjustments target one warehouse and change Quantity on Hand (and therefore Available). You can't change the warehouse after adding products to the adjustment.
Inventory transfers take a source and destination warehouse and are immediate — saving a transfer product row writes both journals and updates both warehouses on the spot.
Manual inventory journals go further: journal type On Hand, On Order or Allocated, and quantities can be negative. They're the integration hook, and they need Field Service 8.2 or later.
Field Service does not enforce non-negative inventory. Adjustments and usage can push Quantity on Hand below zero without complaint.
Users need the Field Service - Administrator role or the Inventory Purchase role to work with warehouses, adjustments, transfers and purchasing.
Inventory transfers are not in the mobile app by default. An admin has to add the Inventory Transfer table to mobile navigation, and both Inventory Transfer and Inventory Transfer Product to the offline profile.

When to use / skip

Turn on Field Service inventory when van stock is the actual business problem — technicians carrying parts, first-time-fix rates tied to what's on the van, and nobody able to say what's in the fleet. For that job the native model is fine and needs no integration.

Skip it when the client already runs stock properly in an ERP and wants Field Service to consume rather than own it. Two systems both claiming to hold on-hand quantities is a reconciliation project nobody costed. In that case use Supply Chain Management or the client's ERP as master and either sync levels in or drop the tracking flag entirely, keeping work order products purely as billing lines.

Also skip it where "parts" are consumables nobody counts. Cable ties and sealant do not need a ledger; making them inventory products just generates negative balances and irritation.

Configuration decisions

Which products are genuinely Inventory type versus non-inventory. This is the single decision that determines whether inventory works at all, and it's per product.
Whether every technician gets a warehouse, or whether vans are pooled by team or region. One warehouse per van is honest but multiplies the maintenance.
How opening balances land: adjustments, manual journals, or an integration load. Pick one and make it the documented method.
Whether replenishment is a Field Service transfer, a purchase order to the van, or an ERP process outside the system.
Whether allocation is used at all. Allocating on Estimated lines gives a truer picture but only if dispatchers actually maintain line statuses.
Where the boundary sits with finance. Field Service journals are operational; they are not a costed stock ledger, and someone has to own that gap.

Gotchas

The commonest support call is "inventory didn't decrement". It's nearly always the product's Field Service Product Type, or a missing warehouse on the resource, or a line status that never reached Used. Fixing the product type afterwards does not backfill the movements — you adjust manually.
Negative on-hand is allowed and silent. Nothing blocks it, nothing alerts on it, and by the time someone notices, the trail is months long. Build a view or a flow that watches for it.
Transfers commit on save of the product line. There is no draft-then-post step, so a mistyped quantity is already in the ledger and needs a correcting transfer.
Changing the assigned resource on a booking doesn't retrospectively move the stock that was already deducted from the previous technician's van.
The mobile gap for transfers surprises clients who demo it on the web app. Van-to-van transfers in the field need the admin steps above, done deliberately.
Manual journals bypass the surrounding process on purpose. That's what makes them useful for integration and dangerous in end-user hands — keep the Inventory Purchase role off technicians unless you mean it.

Consultant notes

Ask early what the client's current stock accuracy actually is. If it's poor on paper it will be poor in Dataverse, and Field Service will simply make it visible — which is worth saying out loud before go-live.
Demo the full loop once: purchase to warehouse, transfer to van, use on a work order, return the surplus. Seeing all four quantities move is what makes the model click.
Push back on modelling every consumable. Agree a value or criticality threshold for what gets tracked.
Before go-live, confirm every bookable resource that carries stock has a warehouse, and spot-check that a completed work order actually wrote journals.
If an ERP is in the picture, settle who is master on day one and write it into the design. Retrofitting that decision is the expensive version.

Worth revisiting if the client adds an ERP integration, or if non-negative inventory controls ever ship natively.