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, 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 visits have dependencies, the default behavior is to leave the preceding visit unassigned if assigning it would prevent the dependent visit from also being assigned. In some scenarios, it is preferable to assign the preceding visit anyway, even if the follow-up cannot be scheduled. It should be possible to configure this behavior, both per individual dependency and as a dataset-wide default.

When a technician has a fixed break scheduled and there is enough time to travel to the next visit before the break starts, the solver should allow that travel to happen before the break rather than forcing the technician to wait and travel after. Currently, the solver defers travel until after the break even when travel could be completed in the available window before the break, leading to suboptimal itineraries where technicians wait idle before a break and arrive later than necessary. This should apply to fixed breaks, floating breaks, and cases where multiple consecutive breaks precede the next visit.

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.

When defining a dependency: splitting a multi-day task into separate visits, it could be useful to define that the second part needs to be finished on the next working day. This will allow the first part to be scheduled on a Friday.

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

When planning field service routes, some shifts should be capped at a maximum number of visits, both as a hard limit that must never be exceeded, or a soft limit the optimizer tries to respect but can breach if needed. We'd like maxVisits and maxSoftVisits fields on the shift object, so limits can be defined per shift rather than globally.

When planning multiday itineraries (e.g. a technician traveling to a distant location for several days), the current workaround is to model a single long shift with hotel breaks. This leads to wrong cost calculations. We'd like a way to link individual daily shifts together, so that costs are calculated per working day rather than across the full multiday span. This would produce accurate cost reporting and prevent the optimizer from generating solutions where visits are clustered on a single day while costs are counted for the entire week.