Feature Requests

For a visit dependency A→B, add a hard constraint guaranteeing that A is never assigned while B is unassigned — so the pair is either planned together or not at all. Current gap The existing prerequisite-assigned constraint ensures B is never scheduled without A, but nothing enforces the other direction. The solver can schedule A and leave B unassigned — including onto a vehicle that, under coordination: SAME_VEHICLE, can never serve B (outside its coverage area or missing a required skill), making B permanently unassignable with no hard score impact. Use case Our preceding visits are parts collections from depots feeding a repair job on the same vehicle. A parts pickup without its repair job is pure wasted work: an engineer drives to collect parts for a visit that isn't happening — and if the pickup lands on a van that can't reach or do the job, the pair can never be completed together. This gap has forced us to move the affected jobs back to manual planning.

As discussed with Luciana: A couple weeks ago we talked about the consecutive shifts worked rule and how it did not yield the desired result from a business point of view. We would like to go ahead with the proposed change to scope the sequence definition to shift tags similar to how MIN_SHIFTS_WORKED_CONSECUTIVELY works. Currently a shift from 9:30 - 18:00 is accepted as part of the sequence because it starts less than 32 hours from the shift 23:00 - 07:00. This is not desired because it is not a night shift. There should be 48 hours of rest after the 23:00 - 07:00 shift in this instance. If I remember correctly all that is necessary to achieve the desired result is to have the sequenceDefinition be scoped by shift tags. As mentioned above this has been discussed with Luciana and we refer to her for any details.

Today, employee pairing / GroupByEmployeeTag lets us tag a group of employees (e.g. a "Car" or "Team" tag) so the solver tries to schedule them together. However, the group isn't strictly kept together. It can end up split into multiple shifts on the same day, or spread across different locations/roles at different times. We need the ability to require that every employee sharing a group tag works the exact same shift (same start and end time, same location) for the entire day, every day of the week. Different employees in the group can perform different tasks/roles, but their hours must always match. Example: a group of employees is tagged "Shuttle bus 1". They may do different jobs, but their shift start and end times must always be identical.

Today, technician coverage areas are defined at the vehicle level. For technicians who operate across very large geographical areas, this is too coarse: the area they should focus on can vary from shift to shift. The request is to allow defining a coverage area per shift, so that the solver can restrict or prefer visits within a specific geographical zone for that particular shift. This should work for both preferred and required coverage area configurations.

As a user of the Timefold models, I want to decide when a new minor model version becomes active in my production environment, so I can first test the new version in my staging/UAT tenant. This helps us validate behavioral changes before they impact real operations, without blocking your regular release cadence.

When an employee has multiple skills, all matching skills are currently treated equally. It should be possible to assign different weights per skill type, so that a stronger skill match is preferred over a weaker one when assigning employees to shifts. This would work analogously to how tagTypeMatchMultipliers already works for shift tag types.

Right now we can view the input and output for plans, however when we use the recommendation api we cannot view those details. It would also be great if those can also be viewed in that UI for troubleshooting purposed.

When a solve completes, the dataset output currently doesn't include any information about when the solver last made a meaningful improvement to the solution. This makes it hard to detect solves that completed normally but plateaued early. By adding a "timestamp of last solution improvement" to the dataset output, customers can compare it against the solve termination time, and decide whether the solve behaved as expected.

Context: When a solve completes but fails to properly optimize ( stalling or plateauing at a suboptimal solution) there is currently no automated signal to indicate this. Users only discover the issue through manual review of the route and data after the fact. Feature request: Add a notification mechanism that triggers when a completed solve is detected to have stalled or returned poorly optimized results. This would allow customers to intervene immediately rather than discovering the issue afterwards. Proposed notification channels (either/both): Email to a preconfigured recipient list Webhook that can be monitored programmatically

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.