Crew jobs and multi-resource bookings in Field Service

A lot of field service work needs more than one person — a lift installation needs two technicians plus an apprentice; a large HVAC job needs a lead engineer and an assistant; a complex utility repair needs a crew of four. Dynamics 365 Field Service models this through multi-resource requirements that bind multiple resources to a single work order with coordinated scheduling.

The requirement model. A work order's resource needs are expressed through resource requirements. For multi-resource work, several patterns are available:

• Multiple individual requirements. The work order has one requirement per role (one Engineer, one Apprentice). Each requirement schedules independently — both must be on site simultaneously, which the scheduler enforces.
• Requirement group. A defined group of requirements that must be filled together — the lead-and-assistant pair, for example. The group is treated atomically; cancelling one cancels the linkage.
• Crew. A pre-defined crew of resources that work together regularly. Booking a crew schedules every member at once with one booking action.

Crews. A crew is a Dataverse record representing a named team:

• Crew name — Crew Alpha, Crew Beta, etc.
• Lead — designated lead resource.
• Members — other resources in the crew.
• Crew strategy — Manage Lead Only (only the lead is scheduled, others ride along), Manage As Crew (all members are scheduled, their availability checked).

Crews are useful when the same group of people work together day after day — common in construction, utilities, multi-tech installs. Less useful for ad-hoc partnerships that vary per job.

Synchronised scheduling. The scheduler ensures multi-resource bookings stay synchronised:

• All resources are at the customer site at the same time.
• If one resource becomes unavailable (sickness), the whole booking is re-scheduled or one substitute is found.
• Travel time is computed per resource individually; the scheduler picks a common arrival window.

Skill mixing. Multi-resource requirements often combine different skills — the lead has Senior HVAC certification; the assistant has only Apprentice certification. Each resource matched to its requirement honours the skill requirement. The scheduler picks valid combinations.

Booking representation. On the schedule board, multi-resource bookings show as linked time blocks across each resource's row — same start time, same duration, same customer location. Visual cues highlight that the bookings are part of a group.

Mobile experience. Each resource in a multi-resource booking sees their own booking on their mobile app, with notes that mark it as a crew job (lead vs assistant role). Time recording is per-resource; some organisations track only the lead's time and assume others match.

Customer experience. The customer sees one arrival window, one job, one invoice — not multiple. The customer-facing communications come from the lead resource or the dispatcher.

Cost and billing. Each resource's time posts to the job individually with their cost rate; billing can sum the total or charge a single flat rate per the customer's contract. Lead-vs-assistant pricing tiers are configurable.

Common pitfalls.

• Crew composition that changes daily — modelled as a crew, becomes a maintenance burden. Use individual multi-resource requirements instead.
• One missing member doesn't trigger rescheduling — the whole booking proceeds with reduced staff, leading to unsafe or incomplete work. Configure the scheduler to enforce all-or-nothing on crew jobs where safety matters.
• Cost not distributed correctly — all hours posting to the lead, missing the apprentice's time. Validate posting setup.

Operational reality. Multi-resource scheduling is materially more complex than single-resource. Pilot with a single crew type before rolling out broadly; expect dispatcher training to take longer than expected.