Feature Requests

Currently, the constraint relies on configurable tag match multipliers only, as described here: https://docs.timefold.ai/employee-shift-scheduling/latest/employee-resource-constraints/shift-type-diversity/shift-tag-types For cases where different reward levels are needed for different seniority levels, it would be useful to multiply the reward by the employee's priority. This would significantly reduce the number of tag configurations required.

Currently, there are four built-in priority levels that can be assigned to employees (Critical, High, Normal, Low). In some cases, this may be insufficient. This is a request to add the ability to either expand the priority scale (e.g., 1–10) or provide customizable priority levels similar to the existing shift configuration.

Currently, the model supports configuring shift priorities via unassignedShiftRule in global rules. Shifts with higher priorities are more likely to be assigned. This is a request to also support employee priorities when assigning shifts. When a shift can be assigned to multiple eligible employees, the employee with the higher priority should be preferred.

It would be useful to set a maximum total travel distance per shift, similar to the existing maximum shift travel time constraint. Some use cases are better expressed in kilometers/miles than in minutes (for example when distance-based cost, vehicle range, or contractual limits matter more than duration).

Currently, travelTimeAdjustment can only be configured at the global dataset level, which applies the same adjustment to all vehicles and shifts in a planning problem. In some scenarios, it would be useful to define a travel time adjustment at the vehicle shift level. This would allow modeling known, static differences between vehicle shifts, for example: A vehicle shift that uses a slower vehicle A shift with operational constraints that systematically increase travel time Simulating predictable conditions (e.g. consistently slower shifts) without applying a global adjustment This would be intended to model pre-defined differences between vehicle shifts that are known at planning time.

The model has recently introduced support for counting minutes between specific daily intervals, for example 00:00 - 06:00. The loggedTime could previously account for breaks in a shift not being counted towards that person's working hours, now it cannot, because it does not have any information about when the break happens in the shift, only the duration of said break. Consider a shift spanning between 20:00 - 06:00 and loggedTime of 9 hours (1 hour break). We don't know if any or all of the break falls within the 00:00 to 06:00 interval where we are counting hours. The goal of this request is to support fixed breaks in the model. These would be defined on Shift level, for example (01:00 - 02:00). The constraints that count time worked would pick the break definition and adjust the working time accordingly.

Can we expand the functionality of the recommendation endpoint to allow more than one visit to be taken as input? To be discussed how the suggestions for the groups of visit (not visit group!) would interact.

As a user of the API, I'd like to be able to define multiple minutes-off limits within a single rolling window rule. Currently, the API only allows defining a single limit, such as: consecutiveMinutesOffLimit: 11 * 60 Certain work regulations require more complex rules, such as: 11 hours of continuous rest per 24-hour period, with 1 period per 7×24 hours allowed to be shortened to 8 hours. This can be reformulated as: 6 × 11 hours of rest 1 × 8 hours of rest …per 7×24-hour period. This is an extension of the existing rolling window API.

As a user of the API, I'd like to be able to define conditional rolling rule evaluations, which are used in certain work regulations. An example of such a rule is: If 16 or more night shifts are worked in a 16-week period, then the employee must work an average of 40 hours per week. Such an expression consists of: Condition: If 16 or more night shifts are worked in a 16-week period Consequence: The employee must work an average of 40 hours per week This is an extension of the existing rolling window API.

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