Linked shifts and bulk time window recommendations in FSR, historic shift exclusion and employee pairing improvements in ESS

Today, we're announcing version 1.5 of the Timefold Platform and updates to the Timefold models.

This new version of the Timefold Platform comes with these platform improvements:

Dataset timeline now shown for non-solved datasets
: The dataset timeline is now also visible for datasets that are submitted without solving. Operations such as validation can take a while for large datasets, and the timeline now reflects that progress. Previously, the timeline was only shown when a dataset was submitted for solving.
Maximum constraint weight enforced
: Constraint weights are now capped at 1,000,000,000,000 (one trillion). The limit prevents score overflow and nonsensical optimization results that can occur when weights are set too high. It is enforced when saving a configuration profile and when submitting a dataset.
Maximum distance from road defaults to null (self-hosted only)
: The maximum distance from road parameter now defaults to null for self-hosted instances, meaning no distance limit is applied unless you configure one explicitly. See Installation instructions for details.
Several smaller bug fixes and stability improvements
.

Next to that, this new version of the Timefold Platform comes with updates to these Timefold models:

Field Service Routing (v1 | Stable)

Introduced linked shifts to eliminate repeated travel (preview)
: Vehicles can now define
linkedShifts
which are chains of consecutive shifts that Timefold may treat as one combined shift. This is useful when a job is too long for a single shift or when a technician stays on-site overnight to avoid traveling to a remote location twice. Timefold automatically chooses whether to use the individual shifts or the linked shift, depending on what produces the better schedule. See Linked shifts for details.
Bulk time window recommendations (preview)
: A new bulk recommendations endpoint lets you request time window recommendations for multiple visits at the same time. Unlike visit group recommendations (which require each visit to be assigned to a different technician), bulk recommendations let the optimizer decide whether the visits are best served by a single technician or split across multiple technicians. Submit up to 20 visit IDs in a single request and receive ranked recommendations showing the optimal technician assignments across a given time window. This feature is in preview and might be a subject to change. See Bulk time window recommendations for more details.
Added actual arrival and departure times for re-planning
: When re-planning an active route, the actual times recorded by a technician's mobile app for already-completed or in-progress visits can now be provided directly in the planning input. This allows the solver to anchor the re-plan to what actually happened in the field rather than relying on estimated times from the previous plan, producing a more accurate schedule for all remaining visits. See Actual arrival and departure times for more details
Maximum constraint weight enforced
: Constraint weights are now capped at 1,000,000,000,000 (one trillion).

Employee Shift Scheduling (v1 | Stable)

Historic shifts excluded from constraint matching
: If you define a planning window, constraint matches whose shifts all end before the planning window start are now skipped, both in constraint violations and in metrics. For example, with a planning window starting on 1st July 2026, a Daily shift pairing between two April 2026 shifts is no longer evaluated. See changelog for details.
Machine-readable validation errors and warnings
: Data pipelines that submit schedules often need to detect and handle validation issues automatically. Until now, validation messages were human-readable strings that were difficult to parse programmatically. The endpoint
GET /v1/schedules/{id}/validation-result
now returns structured validation issues that your code can act on directly. Each issue includes a machine-readable
code
(e.g.
EMPLOYEE_REQUIRED_TAGS_IGNORED
), a
severity
(
ERROR
or
WARNING
), and potentially more properties that identify the affected entity, such as the shift or employee that caused the issue. This makes it possible to build automated mitigations. See Machine-readable validation results for full details and examples.
Required tag type for employee pairings
: Employee pairings now support a
commonTagType
field, making it possible to enforce that paired employees work shifts that share the same tag of a given category. This is useful in scenarios where employees not only need to work together but must also cover the same location, route, or department. See requiring a shared tag type for details.
Maximum constraint weight enforced
: Constraint weights are now capped at 1,000,000,000,000 (one trillion).
Several smaller bug fixes
.

Pick-up and Delivery Routing (v1 | Preview)

Maximum constraint weight enforced
: Constraint weights are now capped at 1,000,000,000,000 (one trillion).
Several smaller bug fixes.

Please let us know if you have feedback.