Feature Requests

We would like the PDR model to offer full real-time planning capabilities, similar to what is available in other models. This includes the ability to continuously update the plan based on live inputs (such as new requests, progress updates from drivers, delays, or changes in travel times) and to re-optimize only the parts of the plan that still remain feasible. To achieve this, the PDR model should support concepts such as: generating recommendations during ongoing execution, accepting an input itinerary that reflects the current state of vehicles and tasks, handling fixed visits (tasks that must remain unchanged when re-planning). These capabilities would allow the model to adapt dynamically throughout the day and support operational use cases where conditions change frequently.

This is a request to make it possible to provide actual arrival, start, and departure times for visits in a FSR routing plan. These fields would be optional and allow the solver to re-plan from the current real-world situation rather than relying only on estimated times. When a visit takes longer than expected or travel time increases (for example, due to traffic or equipment failure), providing these actual timestamps helps re-calculate what’s still feasible for the rest of the day. This enables smoother mid-day re-planning, better tracking of deviations from the plan, and more realistic follow-up schedules.

It would be helpful to support service-level agreement (SLA) constraints in the Pick-up & Delivery Routing model, similar to what’s available in the Field Service Routing (FSR) model. This would allow defining deadlines that ideally are respected for each pickup or delivery, ensuring on-time service and better alignment with contractual requirements. Reference: https://docs.timefold.ai/field-service-routing/latest/visit-service-constraints/visit-slas

I've identified two issues in the OpenAPI schema that cause problems when generating client code with openapi-generator-maven-plugin: Issue 1: Missing allOf in Child Schema Definitions Child schemas that inherit from parent schemas are missing the allOf property to properly define inheritance relationships. Issue 2: Incorrect Mixing of allOf and oneOf in Vehicle.requiredArea The requiredArea property in the Vehicle schema incorrectly combines both allOf and oneOf, which causes ambiguous type definitions. Since Polygon and MultiPolygon already extend/implement GeoJsonGeometry, the allOf reference is redundant and creates conflicts. Only oneOf should be used here to indicate that the field accepts either type. Screenshots: in the screenshots you can find a possible solution and the location of the issues. Screenshot 1: Missing allOf in BreakPlan Screenshot 2: Incorrect allOf + oneOf mixing in Vehicle.requiredArea Screenshot 3: Missing allOf in VisitPlan Impact: These issues prevent proper code generation and cause the OpenAPI generator to create incorrect or incomplete model classes. Thanks for your support

This is a request to make it possible to fix certain visits so they must occur at a specific time and be assigned to a specific employee (or vehicle). Some operations manually schedule part of their work in advance and want to ensure these fixed visits remain unchanged during optimization. Currently, the workaround is to model such visits as fixed breaks with locations, but this approach causes issues - especially with technician cost calculations, metrics accuracy, and visit groups. The requested feature would allow users to mark a visit as fixed (with its assigned resource and start time).

This is a request to add a soft-constraint version of the current requiredArea rule. Today, required areas are enforced strictly, but some planning scenarios would benefit from treating them as preferences (for example, preferring that visits stay within a nurse’s area but still allowing exceptions when needed).

This is a request to enhance preferredVehicles by allowing weighted preferences or affinities. Instead of treating all preferences equally, users could assign higher or lower preference levels to vehicles or employees, letting the solver choose more accurately based on ranked suitability or historical patterns.

This is a request to make disruption rules more employee-focused. Currently, global disruption limits (e.g. allowing 1% of shifts to be changed) can still result in uneven outcomes; some employees may experience many disruptions while others are unaffected. Customers would like the ability to minimize or cap disruptions on a per-employee basis, ensuring changes are distributed more evenly. Possible approaches include balancing disruptions across employees or setting a hard limit (for example, allowing no more than 50% of an employee’s shifts to be disrupted). This would better support “human-centric” planning practices.

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.

The Timefold Cloud Platform at app.timefold.ai is hosted in the EU, see https://timefold.ai/terms . For US-centric customers, an instance of the Timefold Cloud Platform fully hosted in the US would also be useful.