Work order lifecycle and system status

What it does

System Status is the six-value choice column on the work order that drives the whole lifecycle. It is mostly written by the platform, not by users: booking status changes roll up into it, and reaching Posted is what triggers invoicing and actuals. Substatus is the free-form lookup you create alongside it to say anything more specific.

Key facts

msdyn_systemstatus has exactly six options: Unscheduled (690970000), Scheduled (690970001), In Progress (690970002), Completed (690970003), Posted (690970004), Canceled (690970005). Older docs and some UI text still call these "Open - Unscheduled" and "Closed - Posted".
New work orders default to Unscheduled. Creating a booking moves it to Scheduled with no user action.
Booking status maps up: Traveling or In Progress on any booking sets the work order to In Progress; all bookings Completed or Canceled sets it to Completed; a cancelled booking with nothing else live drops it back to Unscheduled.
Microsoft's guidance is explicit — do not add, remove or edit the values of the System Status option set. Editing the labels for display is fine. Everything granular belongs in Work Order Substatus (msdyn_workordersubstatus), which ships empty for you to populate.
Every booking status record has a Status completes work order toggle on its Field Service tab. On means reaching that booking status completes the work order outright. Off means it follows the standard mapping, which is how you build a "Partially completed" status that returns the work order to Unscheduled for a follow-up visit.
That toggle only affects bookings created after the change. Existing bookings keep the behaviour they were created with.
Booking status Completed is where the money gets calculated: booking journals, time entries (per Field Service Settings), total billable duration, total cost, and a travel charge product if the service account has a travel charge type and the booking has non-zero travel time.
Moving to Posted generates the invoice for the billing account, creates actuals, and stamps msdyn_ClosedBy and msdyn_TimeClosed. Cancelling also stamps those fields.
Moving to Completed is what converts work order products into customer assets, for any product with Convert to Customer Asset set to Yes.
Deactivating a work order does not deactivate its children. Products, services, time entries and actuals stay active and must be handled separately.

When to use / skip

There is no "skip" here — every work order has a system status. The real decision is how much of your client's process you try to express in it. The common mistake is treating System Status as the process model, because that is what an admin coming from Customer Service expects to do. It isn't. It's a six-state machine the product owns, and the moment you start bending it you break the booking roll-up and the posting logic.

Substatus is where your process lives. Build a substatus set that matches how the client actually talks about jobs — "Awaiting parts", "Quote sent", "Requires second visit", "Failed - customer not on site" — and use it for views, SLAs and reporting. If someone insists the work order status should say "Awaiting parts", the answer is that it will, in the field the users actually look at.

Configuration decisions

Which substatuses you need, and which system status each maps to. Substatus records carry a system status link, so get the mapping right before anyone builds views on top of it.
Whether any custom booking status should complete the work order, and specifically whether you need a partial-completion status for multi-visit jobs.
Whether Posted is a manual back-office action or automated. Most clients want a review gate before invoicing; a few want it fired by flow once all bookings complete.
Whether Field Service Settings should create time entries and actuals on booking completion, and what that means for a Project Operations or finance integration downstream.
Whether cancelled work orders should be a separate substatus set, since Canceled and Posted both close the record but mean very different things to the finance team.
Who gets write access to System Status at all. Left open, dispatchers will set Completed by hand and skip the booking journals.

Gotchas

Editing System Status option set values is a one-way door in practice. Managed solution updates and the product's own plugins assume the six values; removing or renumbering them causes failures that are hard to trace back.
Setting System Status to Completed manually, without the booking reaching Completed, skips booking journals, time entries and cost calculation. The work order looks finished and the numbers are empty.
The Status completes work order toggle not applying to existing bookings catches people mid-project. Change it, test with an old booking, conclude it doesn't work.
Actual Arrival Time and travel duration are populated from the mobile app's status changes. Technicians who update status from the web, or a dispatcher who updates on their behalf at end of day, produce garbage travel data.
Posting is not reversible through the UI. Once actuals and the invoice exist, unwinding them is a data job, not a status change.
Multiple bookings on one work order make the roll-up non-obvious. A single stray Scheduled booking will keep a job out of the Completed view forever.

Consultant notes

Demo the roll-up early with the client's own dispatcher. Watching the work order status change on its own when a booking status moves is what makes the model click, and it heads off the "can we add a status" conversation.
Agree the substatus list in a workshop and write it down as a mapping table. It changes constantly during UAT and undocumented substatus records are where reporting goes wrong.
Push back hard on custom system statuses. Offer substatus, a custom field, or a business process flow instead — one of those three covers almost every request.
Before go-live, check who has the privilege to set Posted, and check that a test work order posts cleanly against the intended price list and billing account. Finding a broken invoice on day one is a very public failure.
If the client has multi-visit work, build and test the partial-completion booking status during the build, not as a UAT fix.

Worth another look if Microsoft revises the work order form or changes what booking completion writes.