Feature Requests

It would be useful to set a maximum total travel distance per shift, similar to the existing maximum shift travel time constraint. Some use cases are better expressed in kilometers/miles than in minutes (for example when distance-based cost, vehicle range, or contractual limits matter more than duration).

Can we expand the functionality of the recommendation endpoint to allow more than one visit to be taken as input? To be discussed how the suggestions for the groups of visit (not visit group!) would interact.

Profit will need to be positive numeric value that will be maximized over the solution and might need precedence over assigning (mandatory) visits.

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.

Today Timefold supports travel by car or bicycle (or other OSRM profile but only one). For some use cases certain employees travel on foot and/or public transport while other travel by car. Ideally the system also helps deciding who will travel on foot and who better travels by car but this could be an extension later on.

Ideally, we should be able to schedule a visit that takes a full day, even if FIXED/FLOATING breaks are defined on the vehicles. In such a scenario: scheduling a full day visits would remove the break from the day and the break can just be assumed to be taken during the service duration of the visit.

In some datasets visits don't get assigned. In this scenario: The visits are 'optional' Part of their time windows fall after the current planning period. Their time windows start days before the planning period. The 'prefer visits scheduled to earliest day' therefore comes with a large score, even for the earliest possible shifts. This prevents them from being assigned, as it's 'cheaper' to not assign them.

This is a request to be able to account for depot stock levels of non-renewable materials when optimizing field service routes. In some scenarios, visits require specific consumable materials or parts (for example, wood from a depot). The model should consider the availability of these non-renewable resources when assigning visits to technicians and depots, ensuring that planned visits are feasible given current stock levels. This would help prevent infeasible plans and improve coordination between inventory management and route optimization.

This is a request to introduce a way to express preferences for assigning certain visits to specific vehicles or employees. Similar to the existing preferredVehicles setting at the visit level, this would let planners favor assigning particular visits to nurses or drivers who prefer or are best suited for them, while still allowing flexibility if needed.

This is a request to make validation errors returned by the FSR model structured and machine-readable. Currently, error messages are text descriptions that vary in format depending on the error type, making them hard to parse programmatically. Customers would like identifiers (e.g. the IDs of the objects causing the error) and other relevant details to be available as separate fields in the error object, instead of being embedded in human-readable strings.