Feature Requests

The current data in the RequireTagsJustification is : "RequireTagsJustification" : { "type" : "object", "properties" : { "visitId" : { "type" : "string" }, "vehicleShiftId" : { "type" : "string" }, "missingTagCount" : { "format" : "int32", "type" : "integer" }, "description" : { "type" : "string" } } What is missing is which of the tags are not met. For example we have a tag that the employee should be male , and another tag is first-aid. With the current response it is not possible know which tag was missing and the justification applies to

Today a FLOATING break accepts a location but the solver ignores it and decides where the break is taken. Travel to and from that location is never counted. Only FIXED breaks are routed to their location. Support confirmed this is current behaviour and that the docs will be updated. Use case. Field service technicians regularly have a stop during the day that has a fixed place but a flexible time: a supplier pickup, a dump run, a parts drop at the depot. It must happen somewhere in a window, say 11:00-15:30, and takes 30 minutes. We model it as a FLOATING break with a location. What happens now. Because the location is ignored, the solver places the break wherever it costs nothing. In our production case it put a supplier pickup 7 km away between two visits that are two doors of the same building, adding 0 m to the route on paper and a 14 km round trip in reality. What we'd like. Treat a FLOATING break with a location like a FIXED break with a location, just with a movable start: cost the travel from the previous standstill to the break and from the break to the next visit, and let the solver pick the start time inside the window so the detour is as cheap as possible. Ideally the BREAK item in the output then carries travelTimeFromPreviousStandstill and travelDistanceMetersFromPreviousStandstill, as it already does for routed FIXED breaks. Why FIXED is not a good substitute. Pinning the pickup to a specific time removes exactly the flexibility the office wants, and in our tests forced a costly reshuffle of the surrounding visits. Reproducer. Same dataset, 1 vehicle, 2 visits 214 m apart, one 30-minute break 7 km away: FLOATING with location: 25.1 km, identical to FLOATING without location FIXED with location: 40.4 km, break routed, travel fields present on the break item

This is a request to prefer routes of vehicles to start far away and then move closer to home, as technicians like leaving early to avoid traffic, but don't like being stuck in traffic at end of a shift.

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.

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.

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.

As discussed with Luciana: A couple weeks ago we talked about the consecutive shifts worked rule and how it did not yield the desired result from a business point of view. We would like to go ahead with the proposed change to scope the sequence definition to shift tags similar to how MIN_SHIFTS_WORKED_CONSECUTIVELY works. Currently a shift from 9:30 - 18:00 is accepted as part of the sequence because it starts less than 32 hours from the shift 23:00 - 07:00. This is not desired because it is not a night shift. There should be 48 hours of rest after the 23:00 - 07:00 shift in this instance. If I remember correctly all that is necessary to achieve the desired result is to have the sequenceDefinition be scoped by shift tags. As mentioned above this has been discussed with Luciana and we refer to her for any details.

Today, employee pairing / GroupByEmployeeTag lets us tag a group of employees (e.g. a "Car" or "Team" tag) so the solver tries to schedule them together. However, the group isn't strictly kept together. It can end up split into multiple shifts on the same day, or spread across different locations/roles at different times. We need the ability to require that every employee sharing a group tag works the exact same shift (same start and end time, same location) for the entire day, every day of the week. Different employees in the group can perform different tasks/roles, but their hours must always match. Example: a group of employees is tagged "Shuttle bus 1". They may do different jobs, but their shift start and end times must always be identical.

As a user of the Timefold models, I want to decide when a new minor model version becomes active in my production environment, so I can first test the new version in my staging/UAT tenant. This helps us validate behavioral changes before they impact real operations, without blocking your regular release cadence.

Right now we can view the input and output for plans, however when we use the recommendation api we cannot view those details. It would also be great if those can also be viewed in that UI for troubleshooting purposed.