Requirement groups and multi-day scheduling

What it does

Two mechanisms for work that doesn't fit the default one-resource-one-slot shape. Requirement groups bundle several requirements so a job gets multiple resources booked to the same slot. Multi-day scheduling spreads a single requirement whose duration exceeds a working day across several days. They are separate features and they do not combine.

Key facts

A requirement group is built from a Requirement Group Template under Resource Scheduling > Settings > Scheduling. The template holds the structure; the group is the instance you book.
Each node has a Select value of All (default — every child must be fulfilled) or Any, and subgroups let you nest the logic.
Part of Same controls how tightly the matched resources must be related: Location is the loosest, then Resource Tree, then Organizational Unit as the most stringent.
All requirements inside a group must have the same duration. To vary individual booking lengths afterwards, set Cascade Crew Changes to No on the booking's Scheduling tab before editing.
Filter limits inside a group: a maximum of 10 values per requirement for Resource Categories, Characteristics and Preferred Resource.
For onsite work the schedule assistant matches resources that can arrive at the same time, not resources that start travelling at the same time.
Requirement group templates attach to Incident Types (Related > Requirement Groups > New Incident Type Requirement Group), so adding the incident type to a work order generates the group. Incident types that carry characteristics can't be related to a requirement group template — put the characteristics on the individual requirements instead.
Requirement groups cannot be scheduled across multiple days. That's a hard limit, not a setting.
Multi-day scheduling needs a bookable resource with work hours, a requirement whose duration exceeds one working day, and an allocation method other than None if you're using the schedule assistant.
Allocation methods are Full Capacity, Remaining Capacity, Percentage Capacity, Evenly Distribute Hours and Front Load Hours. Full Capacity, Percentage Capacity and Evenly Distribute Hours can overbook the resource.
Multi-day bookings are made in daily, weekly or monthly view, not hourly. Specify pattern lets you set exact days and time ranges.
You can put several resources on the same multi-day requirement by booking one at a time with Book rather than Book & Exit. Resources don't need continuous availability; the system totals available hours across the selected dates.
Requirement groups are the flexible-combination answer; crews are the answer when the same people always work together.

When to use / skip

Requirement groups earn their place when the resource mix genuinely varies per job — a two-person lift here, an engineer plus a hired platform there. If the same three people go out in the same van every day, use a crew and save yourself the template maintenance. Multi-day scheduling is for installations and shutdowns, not for a job that happens to overrun; overruns are a booking-status and time-entry problem. Most projects need neither at go-live, and adding both because the client mentioned a big install once is a reliable way to complicate the schedule board for everyone. Where you do need them, decide which one the work needs, because a job that is both multi-resource and multi-day has to be modelled as separate requirements per day and booked individually.

Configuration decisions

Crew versus requirement group for each type of multi-person work, decided per work type rather than globally.
Whether groups are generated from incident types or created ad hoc by dispatchers, which determines how much template maintenance the client signs up for.
The Part of Same setting per template — how much you're willing to constrain matching in exchange for resources who actually work together.
The default allocation method for long jobs, and whether dispatchers are allowed to use the overbooking-capable ones.
Whether long work is one multi-day requirement or several day-sized requirements linked to the work order. The second is uglier and far easier to reschedule.
Where characteristics live when incident types drive requirement groups, since they can't sit on both.

Gotchas

The same-duration rule inside a group catches everyone. A four-hour engineer task and a one-hour crane hire cannot be one group without editing bookings afterwards with cascade turned off.
Groups and multi-day are mutually exclusive, and the failure is unhelpful. Model it as separate requirements per day instead.
Attaching characteristics to an incident type quietly blocks relating a requirement group template to it, which reads as a bug during configuration.
The 10-value cap on categories, characteristics and preferred resources is generous until someone tries to model a skills matrix with it.
Full Capacity and Evenly Distribute Hours will overbook without complaint. Dispatchers reading a green board assume there's headroom.
Rescheduling a multi-day booking is not one drag. Moving a five-day install a week later means unpicking the pattern, and clients expect it to behave like a single appointment.
"Arrive at the same time" means the resources' travel differs, so their departures differ. Anyone reading start-of-travel times on the board will think the booking is wrong.

Consultant notes

Ask for three real examples of multi-person and long-duration jobs in discovery and model them on screen. It resolves the crew-versus-group argument in twenty minutes.
Demo the reschedule, not the schedule. Clients accept the booking flow easily and are surprised by what moving a multi-day job costs.
Push back on requirement groups used to model a fixed team. Crews are cheaper to run and cascade changes properly.
Before go-live, check overbooking behaviour with the client's own allocation method and a resource who already has bookings. Then decide whether dispatchers get access to the risky methods.
If long jobs get rescheduled often, argue for day-sized requirements early. It's harder to sell and much easier to live with.

Worth revisiting if multi-day support ever reaches requirement groups, or when the client's install work starts spanning weeks.