Feature Requests

Demand-curve based scheduling is now an established feature in our model. However, to use it, the user must manually create shifts for the day, and the solver chooses which shifts to assign in order to best meet the demand curve. This request is for the solver to create the shifts itself as part of the demand curve scheduling. So if the input contained the employees and their contracts as well as the demand curve for each day, then the solver would create and assign the shifts to best staff the demand curve. The output would be the newly created shifts and the employees assigned to them. This is a long-term request based on conversations with multiple prospects and clients, most notably Factorial and most recently Tanda. It's something that's been coming up more and more often recently in prospect conversations.

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.

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.

This is a request to make it possible to control the minimum amount of break times, or maximum amount of service time (for a certain period).

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.

When using employee pairing, the current behavior ensures paired employees work at the same time — but not necessarily at the same location. In multi-location datasets, this means one employee could be scheduled in London while their pair is in Paris. Technically paired, but not practically useful in the described scenario. We'd like the ability to attach tag type constraints to employee pairings, so that paired employees must not only work simultaneously but also share the same value for one or more specified tag types (e.g. location, department). The specific location or department wouldn't be fixed upfront — the optimizer would remain free to choose — as long as both employees end up at the same one. This would make employee pairing meaningful in multi-location contexts, without having to artificially restrict each employee's eligibility to a single location in advance (which significantly limits optimization quality).

When a technician has multiple visits spread across several locations, there are cases where those visits need to be handled as a block — no intermediate visits from other clients in between. Today, this can be approximated using visit dependencies with maxDelay, but that forces an upfront decision on both the sequence and the expected delay between visits. In practice this is hard to configure correctly: set maxDelay too tight and valid solutions get rejected, too loose and unrelated visits slip in between. What we need is a way to define a named group of visits that must be scheduled consecutively, without any visits outside the group in between — similar to how PDR handles multi-stop jobs with prohibited pooling. The optimizer should be free to determine the best sequence within the group, without requiring us to hardcode that order in advance.

When visits have different due times set via latestSlaEndTime, it would be useful if the scheduler automatically prioritized visits with tighter deadlines earlier in the planning period — reducing the risk of SLA breaches. Currently, visits with close due times may not be scheduled early enough, leading to unnecessary violations that could have been avoided with deadline-aware ordering.

Many of our clients manage visits that span multiple days, where the duration of a single job exceeds one day. Currently, this scenario cannot be properly handled within their Timefold integration. One possible workaround would be to split a multi-day visit into separate shifts for each day. However, this approach creates practical challenges.

When a vehicle shift performs multiple visits subsequently on the same location, a configurable overhead should be subtracted from the service duration of the subsequent visits. This overhead should only be applied when the visit is performed in isolation and accounts for parking, general admin, ... It needs to be decided whether 'same location' requires an exact match or if a radius of x meters should be applied to consider them on the same location.