Resource pools and deferred assignment

What it does

A pool is a bookable resource of type Pool that stands in for a set of interchangeable resources. Work is booked to the pool now and reassigned to a named member later — usually by a local supervisor who knows who is actually in on the day. It is the answer to "we know we can cover Tuesday, we just don't know who yet".

Key facts

Create a bookable resource with Resource Type set to Pool, then set Pool Type. Members are added as Bookable Resource Group records from Related > Resource's Children, each with a membership date range.
Members should share a resource type — a pool of users, a pool of equipment, a pool of facilities. Crews and other pools cannot be children of a pool.
Start and end location must be Organizational Unit Address or Location Agnostic. Resource Address is not supported for pools.
Derive Capacity From Group Members is the key switch. Set to Yes, pool capacity is calculated from members' calendars and moves as membership changes. Set to No, capacity is a fixed number you maintain by hand.
The schedule assistant can split a requirement across several pool members — an hour of work with no single free member can come back as two members at thirty minutes each.
The schedule assistant does not return pools for onsite work requirements. Pools work for facility and location-agnostic work, not for jobs at the customer's premises.
Reassignment happens on the schedule board. Filter Resource Types to Pool, right-click the pool and choose View Group Members, then drag the booking onto a member.
Two other reassignment routes exist: right-click > Book Substitute, and right-click > Rebook. Rebook resets the booking duration to the default, so the original duration has to be re-entered.
Bookings made to pool members during their non-working hours count twice against pool capacity.
A pool that is fully booked shows as unavailable even when its individual members are free.
A facility pool is a documented variation — use it where you want to commit to "a bay at the Leeds depot" and pick the specific bay nearer the date.

When to use / skip

Pools suit centralised intake with devolved allocation: a national booking team commits capacity, and branch supervisors decide who does what. They also suit shared physical capacity — bays, rigs, meeting rooms — where the customer cares about the slot, not the specific unit.

Skip pools for straightforward mobile field work. The assistant will not return pools for onsite requirements, which rules out the main Field Service scenario outright, and clients who ask for pools after reading the marketing usually want either the schedule assistant's normal behaviour or Resource Scheduling Optimization. Say so early rather than building a pool that never gets suggested.

Also skip them where nobody owns the second step. A pool booking that is never reassigned is a job with no engineer, and the board makes that look fine right up until the morning of.

Configuration decisions

Whether capacity derives from members or is fixed. Derived is more accurate; fixed is more predictable for commercial commitments. Pick per pool, not globally.
Pool location: organisational unit address for a depot, location agnostic for remote or phone-based work. Nothing else is available.
Membership date ranges — whether members are permanent and the ranges are open-ended, or genuinely time-bound.
Who reassigns pool bookings to named members, and by when. This is a process decision that the system will not enforce for you.
Whether facility capacity is modelled as one facility with capacity greater than one, several individual facilities, or a facility pool. All three are valid and they behave differently on the board.
Whether the same resource can sit in more than one pool, and what that does to your capacity figures.

Gotchas

The onsite-requirement exclusion catches nearly everyone. A pool configured perfectly will simply never appear in the assistant for a normal customer-site work order.
The double-counting of non-working-hours bookings against pool capacity quietly erodes availability. If a pool looks fuller than the maths suggests, look for out-of-hours member bookings.
Pool-level availability is all-or-nothing. Members sitting idle while the pool reads as booked is expected behaviour, not a bug, and it confuses dispatchers every time.
Rebook silently resets duration to the default. Use drag and drop or Book Substitute where duration matters.
Adding a crew to a pool is not supported. It fails in ways that are easier to avoid than diagnose.
Choosing Resource Address for a pool's location produces travel behaviour nobody can explain later. Set it correctly at creation.
Unassigned pool bookings do not chase themselves. There is no built-in nudge, so build a view or a flow.

Consultant notes

Ask what problem the client thinks pools solve before agreeing to build them. Nine times in ten the honest answer is "we want the system to decide later", and that is Resource Scheduling Optimization or a deliberately unscheduled requirement backlog, not a pool.
Where pools genuinely fit — depots, workshops, bays — demo the reassignment step explicitly, including that it is manual, so nobody assumes the system allocates on its own.
Build the "pool bookings not yet assigned to a person" view on day one and put it in front of the supervisor. It is the only thing standing between a pool and an unstaffed job.
Push back on derived capacity if the client is making contractual capacity commitments. Fixed capacity is boring and it does not move when someone books a fortnight off.
Before go-live, test a pool booking against a real onsite work order in front of the client so the onsite limitation is discovered in a workshop rather than in production.

Worth revisiting if pools ever become eligible for onsite work requirements in the schedule assistant.