Feature Requests

Some rest regulations require a minimum total amount of rest within a rolling window, accumulated across multiple qualifying periods, not just a minimum number of breaks of a certain length. For example: "72 hours of rest within any 14-day window, split into periods of at least 32 hours each." We'd like a new totalMinutesOff field that works alongside the existing consecutiveMinutesOffMinIntervals . The requirement is met if a single break covers the total, or if multiple breaks each meet the minimum length and together reach it.

Since the introduction of breaks in shifts, there's no way to specify whether a break should count toward minutes worked for a given contract rule. Currently, all rules treat break time the same way, regardless of the type of break or the intent of the rule. In practice, different rules need different behavior. Some rules should exclude break time; others should include it. For example, a paid break might need to count toward total hours worked for one rule, but not for another. We'd like a mechanism — such as break tags — that allows each contract rule to explicitly include or exclude specific types of breaks when calculating minutes worked. This would make break accounting flexible enough to reflect real-world contract structures accurately.

When multiple visits share the same location, it would be valuable to have the route optimizer assign them consecutively within a vehicle's itinerary — so the vehicle doesn't have to travel away and return to the same spot unnecessarily.

This is a request to make validation errors returned by the FSR model structured and machine-readable. Currently, error messages are text descriptions that vary in format depending on the error type, making them hard to parse programmatically. Customers would like identifiers (e.g. the IDs of the objects causing the error) and other relevant details to be available as separate fields in the error object, instead of being embedded in human-readable strings.

The disruption rules allow us to define "disruption windows" where selected shift re-assignments are penalized. Typically, the disruptions in the near future are penalized more than the later disruptions. It would be useful to have a finer granularity for the disruption for use cases where the disruption window is insufficient. One example would be allowing the disruption only when the new shift overlaps with the original (disrupted) shift, or is within a certain scope (e.g. +- 2 hours). The motivation is that the employees have possibly already arranged their plans based on the original shift, so we want the "new" shift to be as close to the original one as possible. This could be a hard constraint, for some employees it's a preference, for others it's a requirement.

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.

All options to specify pairings now require users to provide references to specific employees to pair with. There are scenarios where it would make sense to also allow for pairing based on the tag of the employee.

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.

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.