Resource crews and crew allocation

What it does

A crew is a bookable resource of type Crew that groups other resources who habitually work together — a two-person installation team, an engineer plus a specialist rig, an apprentice shadowing a senior. Book the crew and every member in date range gets their own booking, kept in sync with the crew's.

Key facts

The crew itself is a bookable resource with Resource Type set to Crew, its own name, time zone and start and end location.
Members are added as Bookable Resource Group records from the crew's Related > Resource's Children, each with a From Date and To Date, an optional Crew Member Type, and a toggle marking the member as leader.
Three crew strategies exist: Crew Leader Management, Crew Member Self-Management, and Cascade and Accept Cascade Completely. The strategy decides who drives booking status once work starts.
Under Crew Leader Management there is one leader at a time and the leader must be a User-type resource, because someone has to move the booking through Traveling, In Progress and Completed in the app.
Cascade and Accept Cascade Completely is the right choice for a person-plus-equipment crew, where every member follows the same status throughout.
Member bookings are only created where the booking falls inside the member's From/To date range and inside that member's own work hours for the day. A member with no calendar that day quietly gets nothing.
Booking a crew auto-creates a requirement group with Auto Group Type set to Crew. Only the crew header resource is linked to the original single requirement.
Crew members take their start and end locations from their own resource records, not from the crew header.
The Crew Allocation tool on the Resources view command bar handles day-to-day membership changes by drag and drop. It edits up to 15 crews at once, applies to a single day only, and processes asynchronously.
Crews render with a distinct icon on the schedule board, and the period a resource belongs to a crew shows as a grey band on that resource's row.
Crews matching a board filter appear even when their individual members do not match it.

When to use / skip

Use crews where the pairing is durable — a team that meets at the depot, shares a van and works job to job all day, or a mentoring arrangement that runs for months. That is what the feature is built for and it works well.

Do not use crews for ad hoc "this job needs two people" situations. That is what requirement groups are for, and reaching for a crew instead means creating and dismantling crew records constantly. The tell is whether the composition is decided by the job or by the rota: job-driven means requirement groups, rota-driven means crews.

Also think twice before crewing a resource who also needs to be schedulable alone. Booking a job to one member of a crew consumes the whole crew's availability, so a "sometimes in the crew, sometimes solo" engineer creates a board that reads as much busier than reality. Where that pattern dominates, individual resources plus requirement groups is the calmer design.

Configuration decisions

Crew strategy per crew, driven by who actually holds a phone and updates status. This is the decision that determines whether crews work in the field or become a dispatcher-only fiction.
Whether membership is long-lived (edit the crew resource directly) or changes daily (Crew Allocation). Both are supported; mixing them without a rule causes confusion.
Whether the crew header or the members carry characteristics and territories, given the header is what board filters match on.
Start and end location for the crew header — usually the depot — knowing members still use their own.
Whether apprentices and shadowing arrangements are modelled as crew members or handled outside the system.
How crew capacity is expected to interact with skills: crews with more members than the requirement needs rank lower in the assistant, so oversized crews get suggested less often.

Gotchas

Move a leader to a different crew with Crew Allocation and they lose leadership status for that day, even if you move them straight back. Restoring it means editing the crew resource directly.
Crew Allocation is single-day. Using it for a permanent change gives you one corrected day and a stale crew record underneath.
The tool is asynchronous and blocks further changes while it processes. Expect a wait of minutes on a large reshuffle, and tell the dispatcher that before they click twice.
Members with no work hours on a given day get no booking while the crew shows as booked, so the job looks staffed and isn't.
Crew size mismatch cuts both ways: more members than the requirement needs and the surplus get bookings against the requirement group but not the specific requirement; fewer and the engine will pad the crew with unrelated individual resources.
Completion timing is asymmetric — when the assigned resource marks a booking Completed the end time snaps to now; when someone else does it on their behalf the end time is left alone. Time-and-materials clients notice this.

Consultant notes

Establish who updates booking status in the field before you pick a strategy. Everything else about crews follows from that one answer, and it is an operations question, not a config one.
Demo the crew allocation drag-and-drop to the dispatch team. It is the feature that sells crews, and it is also the one that needs the 15-crew and single-day caveats said out loud.
Push back hard on using crews for variable two-person jobs. Requirement groups do that job and do not need daily maintenance.
Check crew members' individual work hours as part of go-live, not just the crew header's. Missing member calendars are the most common cause of a crew booking that only half exists.
Set expectations on the grey band and shared availability. Dispatchers who expect to book a crew member solo on a quiet afternoon need to know why the system says no.

Worth another look if Crew Allocation gains multi-day editing or the 15-crew limit changes.