Reference · built on requestOperator by FibricFleet, routes & field

Route Overflow

Compares tomorrow's stop counts, load, and hours with each route's limits and proposes moving stops or opening a route.

About

Route Overflow is an operator job that checks tomorrow's plan before drivers see it. For each route it counts stops, adds up the load the route source records, and sums drive and service time to the last stop. It sets each against the route's limits: the truck's maximum deliveries per route, its capacities, and the end of its work hours, or the figures you set where the route source has none.

A route over any limit becomes a case. The operator finds routes with room, drivers on tomorrow's roster who are not yet assigned, and remaining hours of service, then proposes moving the extra stops or opening a route and staffing it. The planner approves each change; the plan is written once, after that.

This is a reference listing. It documents what Fibric would read from Route Overflow and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • DispatchTrack trucks with max_transport_point_count_per_tour, max_driving_period_per_chain, capacity_one, capacity_two, and end_work_time, and the Plan routes webhook with each stop's arrival_time, driving_period, and service_time
  • Stop loads: DispatchTrack stop items with quantity and capacity totals, Onfleet task quantity and serviceTime, order line_items from WooCommerce and BigCommerce
  • Route4Me routes and their addresses with sequence numbers and time windows, and Samsara routes with scheduledArrivalTime and scheduledDepartureTime per stop
  • Onfleet route plans with taskStates, and Bringg driver availability and delivery blocks
  • Tomorrow's roster: Deputy Roster records, returned for the next 36 hours by default, and When I Work shifts with include_open for unfilled shifts
  • Remaining drive, shift, and cycle time per driver from Samsara Get HOS clocks, and available time from Motive GET /v1/available_time

Proposed actions

  • Target capability: propose moving stops to a route with room through Route4Me move_route_destination.php, an Onfleet task reassignment, or a Bringg Assign Driver to Route
  • Target capability: propose opening a route: a Samsara route with a driverId, an Onfleet route plan, or a DispatchTrack plan with an added truck
  • Target capability: propose the shift to staff it: a Deputy shift through POST /api/v1/supervise/roster, or a When I Work shift through POST /2/shifts and /2/shifts/{id}/assign
  • Target capability: propose a planner brief in Slack or Microsoft Teams: each route's stops, load, and hours against its limits, with approve and decline buttons

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Catch a DispatchTrack route over its delivery cap

    The Plan routes webhook gives each route's ordered stops. Counted against the truck's max_transport_point_count_per_tour and end_work_time, the extra stops are proposed for the truck with room, and a Deputy shift for its driver.

    With DispatchTrack, Deputy

  • Rebalance Route4Me routes before publishing

    Addresses past a route's time window are proposed for a neighbouring route through move_route_destination.php. The planner sees both sequences in Slack and approves the move or asks for a new optimization.

    With Route4Me, Slack

  • Open an Onfleet route and fill it from When I Work

    When route plans exceed the quantity or hours you set, the operator proposes a new route plan, the tasks to add, and an open When I Work shift for the driver to be assigned to.

    With Onfleet, When I Work

  • Keep Samsara routes inside HOS clocks

    Remaining drive and shift time from Get HOS clocks is set against each route's scheduled stops. A route that would outrun its driver's clock is proposed for a split into a second route with its own driverId.

    With Samsara, Microsoft Teams

Requirements

  • A route source with tomorrow's routes and stop order: DispatchTrack, Route4Me, Onfleet, Samsara, or Bringg
  • Route limits: the truck fields the route source carries, or a stop count, load, and end time per route set in the operator's configuration
  • A roster connector for tomorrow's drivers: Deputy or When I Work; optional HOS clocks from Samsara or Motive
  • Slack or Microsoft Teams for the planner's approval
Authentication
Holds no credentials. Plans, orders, and rosters are read, and changes proposed, through the connectors you bind, each under the access it carries.

Limits

  • Load is counted only where a record carries it: DispatchTrack item capacities and Onfleet quantity. Commerce orders contribute line counts, not weight
  • Time is the planner's arrival_time, driving_period, and service_time. Live traffic is not read unless a signal that carries it is bound
  • Opening a route stops at the proposal. The truck, the plan, and the shift exist only after the planner approves each one
  • A stop moves only to a route that stays inside its limits after the move. When none does, the case is reported without a proposal

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Route Overflow ↗

Questions and answers

What does the planner approve?
A brief per route over a limit: stops, load, and hours against the truck's limits, the stops proposed to move and where, or the new route and the shift to staff it. Each change carries approve and decline. Approving writes that change and no other.
What record is kept?
Per case: the routes and limits read, the roster and HOS records compared, each proposal with its figures, the planner's answer and time, and the moves, routes, and shifts as the route source and roster accepted them.
Can it open a route or add a shift by itself?
No. A route, a truck, and a shift are created only after a planner approves that proposal, and each is created once. The operator does not re-optimize routes, publish rosters, or notify drivers on its own.
Ask about Route Overflow

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.