Feature Requests

We send a week of unpinned shifts but for WorkingHours Act we need to send 52 weeks in the past and future of pinned shifts. So most shifts that are returned are pinned. We have to filter them. This makes the answer from Timefold much bigger than we need. It would be great if we can tell to Timefold to only send the unpinned shifts back.

Currently rolling windows support HOURLY, DAILY, WEEKLY. Being able to add MONTHLY would be very helpful for the customers using union agreement rules such as Max X hours in 4 months, Min X hours in 4 months. If we're using periodRules for "MONTH" and dividing X with 4, this removes the flexibility of being able to work a lot of hours in a single month, and a few in the next. In theory it would probably work with a rollingWindowRules type: "DAILY" and size: "amount of calendar days in 4 months" however, this would be cumbersome as the amount of days in a month varies. There might be another way to solve this, but here is an example of what I suggest: The employee can work a maximum of 400 hours in 4 months { "contracts": [ { "id": "fullTimeContract", "rollingWindowRules": [ { "id": "max24000MinutesRollingWindow", "rollingWindow": { "type": "MONTHLY", "size": 4 }, "minutesWorkedLimit": { "minutesWorkedMax": 24000 }, "satisfiability": "REQUIRED" } ] } ] } The rules are looking at rolling windows, and defined by calendar month. ----- CONTEXT ----- Let's say we're allocating a 4 month schedule starting April 1st, and we're sending historic data as pinned shifts. From January 1st to March 31st the employee has had 300 hours of work. This means the employee can work a maximum of 100 hours in April. From February 1st to March 31st the employee has worked 100 hours. This means the employee can work a maximum of 200 hours in May (assuming the employee got 100 hours allocated in April)

Currently, demand rules only support hourly intervals. To express a constant demand from 9:00 to 17:00, you have to enumerate up to 16 separate intervals; one per hour (or per 30 minutes). This is verbose and error-prone. We'd like demand intervals to support arbitrary durations, so a single interval like "startDateTime": "2025-12-04T09:00:00Z", "endDateTime": "2025-12-04T17:00:00Z" can express the same thing. The demand should be enforced at every point within the interval, not just at the start.

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.