Feature Requests

This is a request to add an API capability that returns only the differences in assignments or itineraries between two datasets. The goal is to help customers process just the changed parts of a plan after replanning, instead of handling the entire updated plan (which may include thousands of assignments). This would reduce overhead in downstream systems, where only changes—such as new or modified tasks—need to be acted upon.

Today Timefold supports travel by car (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.

We currently do not support introducing waiting time to adhere to 'minDelay' dependencies where it is sensible. Two visits, One vehicle, Two vehicleShifts. Visit B has a dependency on Visit A with a minDelay of 1H When planning these two visits, the model has no way to introduce waiting time (and plan both on the same vehicle) It will therefore plan this visit B on the next day/shift.

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.

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.

This is a request to make validation errors returned by the ESS 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.

Investigate whether we can expand travelTimeAdjustment with geocode information to configure the adjustment for a certain (e.g. London) area instead of over all.

This request is to allow configuring traffic impact on various dimensions (time, region etc) to adjust expected travel time for known traffic impact.

This is a request to make it possible to see details on the shifts that are left unassigned when looking at a solved Employee Shift Scheduling problem.

Allow bearer tokens as authentication method on webhooks