Feature Requests

For a visit dependency A→B, add a hard constraint guaranteeing that A is never assigned while B is unassigned — so the pair is either planned together or not at all. Current gap The existing prerequisite-assigned constraint ensures B is never scheduled without A, but nothing enforces the other direction. The solver can schedule A and leave B unassigned — including onto a vehicle that, under coordination: SAME_VEHICLE, can never serve B (outside its coverage area or missing a required skill), making B permanently unassignable with no hard score impact. Use case Our preceding visits are parts collections from depots feeding a repair job on the same vehicle. A parts pickup without its repair job is pure wasted work: an engineer drives to collect parts for a visit that isn't happening — and if the pickup lands on a van that can't reach or do the job, the pair can never be completed together. This gap has forced us to move the affected jobs back to manual planning.

Today, technician coverage areas are defined at the vehicle level. For technicians who operate across very large geographical areas, this is too coarse: the area they should focus on can vary from shift to shift. The request is to allow defining a coverage area per shift, so that the solver can restrict or prefer visits within a specific geographical zone for that particular shift. This should work for both preferred and required coverage area configurations.

When multiple vehicles serve overlapping areas, routes can end up long and sprawling, with vehicles criss-crossing each other's paths. Planners may prefer routes that stay geographically compact, where each vehicle's visits are clustered in one area rather than spread across the map, even if a more spread-out route would be marginally more optimal by travel time alone. This is a soft preference: compact, non-intersecting routes improve driver experience and make plans easier to understand and trust at a glance. One possible approach: penalize each vehicle shift based on the maximum travel time between any two visits assigned to it, encouraging tighter geographic clustering.

When balancing workload across technicians, some technicians have a higher target workload than others. For example, a technician contracted for overtime may have a 1.2 FTE target while a standard full-time technician has a 1.0 FTE target. Load balancing should take these individual FTE targets into account, so that each technician is balanced relative to their own target rather than a single uniform baseline. This is analogous to how FTE-based load balancing already works in Employee Shift Scheduling. See https://docs.timefold.ai/employee-shift-scheduling/latest/employee-resource-constraints/fairness/balance-time-worked#_factoring_in_full_time_equivalent

Beyond plan-level profit and cost totals, planners need per-vehicle breakdowns to assess the financial value of individual routes. This makes it possible to compare routes on financial terms, for example understanding that one route generates significantly more revenue than another.

Many of our clients manage visits that span multiple days, where the duration of a single job exceeds one day. Currently, this scenario cannot be properly handled within their Timefold integration. One possible workaround would be to split a multi-day visit into separate shifts for each day. However, this approach creates practical challenges.

Currently, the input needs to specify which technicians can travel during the planning period (by including multi days shifts with hotel breaks). However, is some cases travelling is not strictly necessary and all itineraries could be performed with technicians leaving from and returning to their home location. This might produce confusing outputs and/or suboptimal schedules. See https://app.timefold.ai/e185e9c6-19a8-4f90-afcc-56bce43ff6a5/models/field-service-routing/v1/runs/288d5b97-9e69-4e88-8969-1ea6dc42c110 Visit 6517503 is only performed on Friday with an assumed waiting time of 4days.

Recently in release 1.25.0 a new feature was added durationAddedForFirstVisitOnLocation to support for example a parking time. This is fine when we have visits on the same location and only heed to take into account the overhead of parking once. However we also have the overhead of administration / paperwork that is needed only once per customer on a location. This is the case when we have an apartment building, here all customers have the same location / coordinates but we still need to possibility to add some overhead. Another type of overhead is internal travel time, for example a large building block where we have 2 customers. Here the employee needs to walk / elevator / stairs between the customers. The diagram below should cover the scenario's described above.

Today, skill multipliers can be configured at the shift level to account for differences in technician productivity or capability. However, there is no way to apply a general multiplier at the vehicle level that would carry through to all shifts for that vehicle. This would be useful for cases where a blanket productivity buffer is needed for a specific vehicle or technician (for example, someone new to the job), without having to configure the multiplier on each individual shift separately.

Today, the "prefer grouping colocated visits" constraint rewards a technician for doing consecutive visits at the exact same location, reducing unnecessary travel. However, in practice, visits near each other (but not at the identical location) would benefit from the same grouping logic. The request is to extend this constraint with a configurable radius, so that visits within a specified distance of each other are treated as a group and preferably scheduled consecutively. This makes the constraint more useful for real-world datasets where nearby visits are effectively colocated from an operational standpoint.