Feature Requests

This is a request to make it possible to automatically insert breaks into shifts as part of the scheduling output, in order to comply with e.g. labor laws or internal policies. For example, in an 8-hour shift a break is required, but the exact timing may vary and not all breaks should overlap across employees, to ensure proper coverage. Having breaks generated by the scheduler would ensure they are feasible, legally compliant, and aligned with operational constraints, instead of requiring manual break planning after the schedule is created. Why this matters: Today, breaks have to be decided manually by users, which is time-consuming and error-prone. Automatically assigning breaks would reduce manual work, improve compliance, and produce schedules that are immediately executable.

We would like the ability to securely store and manage sensitive values (such as API keys or tokens) and reuse them across integrations without exposing them in configuration screens or logs. This makes it possible to centralize credentials, rotate them when needed, and avoid duplicating sensitive values across multiple integrations. This is especially important when configuring e.g. webhooks that require authentication, while still meeting security and compliance requirements.

It should be possible to define shifts that require multiple mandatory skills while also allowing a choice between alternative skills. For example, a shift may require skills A and B, and additionally require one of C or D. Today, skill requirements can be defined as either “all required” or “choose one from a list,” but not both at the same time. This makes it hard to model realistic skill requirements without creating artificial or duplicated skills. Supporting combined required and alternative skills would make schedules more accurate, easier to configure, and closer to real-world qualification rules.

The Timefold Cloud Platforms are hosted in EU or US. This is a request to have an environment of the platform hosted in Canada for Canada-based companies.

We would like the PDR model to offer full real-time planning capabilities, similar to what is available in other models. This includes the ability to continuously update the plan based on live inputs (such as new requests, progress updates from drivers, delays, or changes in travel times) and to re-optimize only the parts of the plan that still remain feasible. To achieve this, the PDR model should support concepts such as: generating recommendations during ongoing execution, accepting an input itinerary that reflects the current state of vehicles and tasks, handling fixed visits (tasks that must remain unchanged when re-planning). These capabilities would allow the model to adapt dynamically throughout the day and support operational use cases where conditions change frequently.

This is a request to extend the existing dependency rules by allowing a maximum delay ( maxDelayTo ) between visits, in addition to the current minimum delay ( minDelayTo ). This would make it possible to define flexible but time-bounded visit patterns, such as “three visits per week with at least one day and at most two days between them,” or “two visits on the same day with no more than four hours in between.”

We would like the ability to disable email/password login for users belonging to a specific email domain and require them to authenticate exclusively through SSO (for example, Google Workspace or another identity provider). This means users from that domain should not be able to create or use a separate email/password combination, ensuring that all access goes through the organization’s approved authentication flow. This is important for meeting internal security policies, enforcing consistent access controls, and preventing users from bypassing organizational identity requirements. Even if the platform does not store passwords, having domain-level SSO enforcement ensures that authentication remains fully centralized and compliant.

It would be helpful if users could be provisioned automatically through our existing SSO or identity provider integration (for example, using SAML or SCIM). This would simplify user management by ensuring accounts are created, updated, or deactivated automatically when changes happen in the organization’s identity provider. Even though manual user management works fine for smaller teams, automated provisioning would reduce admin effort and improve security for larger deployments or organizations using tools like Auth0, Okta, or Azure AD.

Several working regulations have requirements for hours worked between certain times of day. For example, an employee might have a limit of 40 hours per week maximum, but at the same time have an additional limit of 30 hours of work between 00:00 and 06:00 in every 14 days. Provide a way to specify the time interval for period and rolling window rules. Example rule: rolling window: (WEEK, size 2) includeTimeOverlap: (start: 00:00, end: 06:00) minutesWorkedMax: 30 * 60

Currently the API does not allow a logged time for a shift to be > the actual shift duration. Could this restriction be lifted? Thanks.