Feature Requests

The consecutive constraints in the model currently operate with the day granularity only. That means, if we have the following shifts assigned to an employee: Day 1, 18:00 - 22:00 Day 3 02:00 - 06:00 Day 4 02:00 - 06:00 This produces 2 daily sequences [Day 1], [Day 3, Day 4], because we look at shift's start times. Some use cases treat sequences differently. There is a scope (for example 36 hours). If the shifts are not separated by more than the 36-hour limit, they are treated as a single sequence. In the example above, the shifts would be consecutive, since "Day 1" and "Day 3" shifts are separated by 28 hours. This is a request to introduce the new scope concept to the "consecutive shifts worked" rules, so that we can express rules like "Maximum 7 consecutive shifts in a sequence". Moreover, the constraint ideally supports "filtering" case too, such as "Maximum 7 consecutive shifts in a sequence containing one or more night shifts".

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.

We would like to request gRPC support as an alternative to the current REST API for interacting with the Timefold Platform. gRPC would provide significant advantages for large-scale scheduling and analysis workloads: Faster communication with binary serialization, reducing payload size and latency for large planning datasets Type-safe contracts via Protocol Buffers, ensuring clients and servers are fully aligned while allowing development.

We would like to request multi-language support for the /analyze endpoint in Timefold Platform, allowing constraint violation descriptions and related message fields to be returned in a configurable language. Currently, the constraint violation explanations and message texts are returned in English only. For production systems used by non-English-speaking users, this creates a usability barrier when presenting analysis results directly in user interfaces. Proposed Enhancement Add support for localized output from /analyze, where message text and constraint violation explanations can be returned in a requested language. Possible approaches: Option A — Request Language Parameter Allow clients to specify a language via: HTTP header (preferred): Accept-Language: da-DK or query parameter: /analyze?lang=da The endpoint would then return localized messages when translations exist. Option B — Message Keys Return stable message keys and parameters alongside the message text, allowing either server-side or client-side localization using language templates mapped to those keys. We would be happy to assist by providing a Danish translation template as an initial contribution.

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.

This is a request to make validation errors returned by the ESS 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.

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, 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).