What it does

Multi-visit work is modelled one of two ways. Either one work order carries several bookings — one per visit — or each visit gets its own work order, related back to a case, an agreement or a parent record. Field Service supports both, and the platform's status rollup logic is what actually decides which one behaves sensibly for a given business. Pick this early: it's the shape of your reporting, your billing and your dispatcher's day.

Key facts

• A work order has six system statuses: Unscheduled, Scheduled, In Progress, Completed, Posted, Cancelled. You cannot add to that set — custom system statuses get no icon and no colour. Extend with substatuses mapped onto system statuses.
• Work order status is a rollup of its bookings. If any booking is In Progress, the work order is In Progress. The work order only reaches Completed when all its bookings are completed or cancelled.
• A booking that is Scheduled alongside one that is Completed still leaves the work order In Progress. That's the crux of the per-job model: a partially done job reads as in progress, which may not be what the business wants.
• Default booking statuses are Scheduled, Travelling, In Progress, On Break, Completed and Cancelled, updated by technicians on the mobile app.
• The earliest Actual Arrival Time across bookings populates the work order's First Arrived On field — so first-time-fix and arrival SLA metrics are computed against the first visit, not each visit.
• Moving a work order to Posted generates invoices and Actuals records. Billing granularity therefore follows work order granularity, not booking granularity.
• Requirements are generated from work orders, and multiple bookings on one work order is the supported pattern for multi-day and multi-resource work.

When to use / skip

Default to one work order per job with multiple bookings. It matches how the platform's status rollup, First Arrived On and posting logic are designed, it keeps the customer-facing record singular, and it means a technician returning to finish the same fault sees the same work order with the same history, parts and inspections attached.

Go to one work order per visit when one of three things is true. Billing: if each visit is invoiced separately, per-visit work orders line up with the Posted-generates-invoice behaviour and save a nasty split at the billing stage. Independence: if visits are genuinely distinct work with different incident types and different parts — a planned maintenance round rather than one job over several days — they're separate jobs, and pretending otherwise makes the record incoherent. Handoff: where each visit is assigned and accounted for separately, and the work order status needs to reflect that visit rather than the aggregate.

The failure mode I see most often is the mixed model with no rule. Some jobs get extra bookings, some spawn new work orders, and after a year nobody can answer "how many jobs did we do" because the denominator is unstable. Pick one default and document the exceptions.

For agreement-driven planned maintenance the pattern is settled for you: the agreement generates a work order per scheduled date, so don't fight it. For reactive work with follow-up visits, one work order and repeat bookings is usually right. For long installations with staged sign-off, per-visit work orders under a parent record hold up better.

Configuration decisions

• Pick the default granularity and write it down as a design decision, with the named exceptions. This is the deliverable, not the config.
• Decide the parent record for multi-work-order jobs: case, agreement, project, or a custom "job" table. Reporting hangs off this choice.
• Design your substatus set against the six system statuses, and decide what "returning next week" looks like — a substatus on an in-progress work order, or a closed work order plus a new one.
• Decide how the mobile technician indicates "not finished, coming back". Booking status alone doesn't express it; you'll need a substatus, a resolution, or a flag on the work order.
• Decide where billing granularity sits, because Posted is per work order. If invoicing is per visit and work orders are per job, you're building something custom.
• Agree the reporting definition of a "job" and a "visit" before build, and confirm both are derivable from the model you pick.

Gotchas

• Work order status does not go Completed until every booking is completed or cancelled. Abandoned bookings left in Scheduled will hold work orders open indefinitely, and this shows up as a growing backlog nobody can explain.
• First Arrived On takes the earliest arrival across all bookings. In a per-job model, SLA arrival metrics measure the first visit only — often what you want for response SLAs, rarely what you want for completion metrics.
• Custom system statuses aren't supported. Teams design an eight-stage lifecycle in workshops, then discover it must be substatuses after the reporting spec is written.
• Posting is per work order, so a per-job model with per-visit billing requires custom logic on actuals. Find this in design, not in the finance UAT.
• Moving from per-job to per-visit later means splitting historical work orders and reallocating actuals, bookings and inspections. Treat it as a one-way door.
• Multi-resource work — several technicians on one job — is bookings on one work order by design. Even with per-visit work orders as your default you still need multiple bookings for crews, so the model is never purely one or the other. Cancel-and-rebook versus reschedule also needs a convention, or visit counts come out wrong.

Consultant notes

• Run this decision in a workshop with operations and finance in the same room. It looks like a technical modelling question and it is actually a billing question.
• Demo the status rollup live: create a work order, add two bookings, complete one, and show that the work order stays In Progress. That single demo settles most of the argument.
• Ask "how do you count a job today?" before proposing a model. Matching the existing number matters more to the client than elegance.
• Push back on the mixed model without a rule. If exceptions are needed, name them and constrain them to specific work order types.
• Before go-live, check for bookings stuck in Scheduled on completed jobs and put a monitoring view in place for it. It's the cheapest data-quality control on the whole build.

---

Worth another look if Microsoft ever opens up work order system statuses, or if the agreement generation pattern changes.