Drivers & Fleet: The Catalogs Behind Collections

A collection that fails because the wrong vehicle was sent or the wrong driver was scheduled is a category of mistake the platform’s catalogs are built to prevent. /settings/core/drivers and /settings/core/fleet are the catalogs the scheduling flow draws from.

Drivers

Each driver row carries: name, contact details, employer (own staff or third-party), license class (B for vans, C for trucks, etc.), security-clearance level (some sites require background-checked drivers), home-warehouse for routing optimization, active/inactive flag for when a driver is on leave or has left. A collection’s assignment dropdown filters drivers by the warehouse and the license class needed for the assigned vehicle.

Vehicles

Each vehicle row carries: registration plate, make/model, capacity (tonnage and volume), license-class required, fuel type, home-warehouse, the active driver assigned (or unassigned for shared pool vehicles), maintenance dates (next service due, last MOT). A collection’s vehicle dropdown filters by capacity vs. expected load, by warehouse, by maintenance status (a vehicle past its MOT date doesn’t appear in the available list).

Why both catalogs

Because drivers and vehicles aren’t one-to-one. A driver can use any vehicle they’re licensed for; a vehicle can have multiple drivers across shifts. Treating them as separate rows and matching at collection-assignment time is what makes the dispatch flow work without rewriting the data each cycle.

Per-collection assignment

From the collection detail page, the dispatcher picks a driver and a vehicle. The platform validates the combination (license class match, capacity sufficient, both active, vehicle’s next service is past the collection date). Mismatches surface as warnings — not blockers, because real life sometimes overrides the catalogs — with the option to record a reason for the override.