Richer dataset comparisons, CSV exports, and smarter visit dependency controls in FSR

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

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

Richer, more readable dataset comparisons: The comparison table now includes a Model info section showing each dataset's model version, solver version, SDK version, build time, build commit, and branch, so you can compare across model versions when benchmarking or debugging. You can now compare constraint scores across sets of datasets, not just individual ones, and the comparison view has several slight UI improvements: columns are easier to read, and tooltips are clearer.
Export the plans overview to CSV: The plans overview table now has an Export CSV button that downloads the latest 100 plans matching your current search and filters.
Manually trigger a queued solve: The solve queue now has a "Run now" action that lets you manually trigger a queued execution instead of waiting for it to start automatically.
Clearer validation for traffic-aware routing: Configuring traffic-aware routing for a map without traffic data now returns a clear validation error instead of an unclear or unexpected failure.
Consistent tenant switching: Switching tenants now keeps you on the equivalent section of the new tenant, for example a webhook detail page lands on the new tenant's webhooks overview, instead of always redirecting you to the homepage.
Persisted table column settings: Column visibility and order selections are now persisted across tenant management tables.

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

Field Service Routing (v1 | Stable)

Visit dependencies can now restrict pooling with other visits: By default, other visits can be freely scheduled between the preceding and following visit of a dependency, and multiple dependency pairs can be interleaved with one another. A new
poolingType
attribute on
visitDependency
lets you restrict this per dependency, and a new
config.model.overrides.defaultDependencyPoolingType
setting lets you change the default for the entire dataset. Setting
"poolingType": "DISALLOW_POOLING"
prevents any other visit from being scheduled directly between the preceding and following visit.
ALLOW_POOLING_VISITS
and
ALLOW_POOLING_DEPENDENCIES
allow pooling with only one of ordinary visits or other dependency pairs, respectively. This is useful when, for example, a technician must go straight from an equipment delivery to its installation without an unrelated job in between.
Visit dependencies can be restricted to the same shift: Previously, the preceding and following visits of a dependency could be scheduled in any vehicle shifts or restricted to vehicle shifts of the same vehicle by
"coordination": "SAME_VEHICLE"
. Timefold now allows restricting the preceding and following visits to the same vehicle shift by specifying
"coordination": "SAME_SHIFT"
.
Fixed next visit incorrectly pinned when fixed-location breaks precede it: With the default
pinNextVisitDuringFreeze
setting (
ALWAYS
), Timefold pins the visit a vehicle is already traveling to when
freezeTime
is applied. When one or more fixed-location breaks were scheduled before a visit, Timefold could pin that visit as soon as the time of traveling to those fixed breaks was before
freezeTime
, even though the technician had only committed to traveling to (or taking) the fixed break(s), not to the visit itself. Timefold now accounts for fixed-location breaks preceding visits and only pins the visit once the vehicle has actually departed toward it, that is, after the last such break ends.
Improved solution quality for grouping co-located visits: The Prefer grouping co-located visits constraint encourages assigning visits that share the same location consecutively in a vehicle shift's itinerary, so the vehicle can perform them without traveling in between. Timefold now uses a dedicated move that specifically targets visits sharing the same location and moves them next to each other, either within the same vehicle shift or across vehicle shifts. This results in higher quality solutions when the constraint is enabled.
More accurate route lines on the map when breaks have a fixed location: The Map view's route lines previously only followed a vehicle shift's start location, visits, and end location, so a fixed-location break in between was not reflected in the drawn road path. Breaks with a location are now included when computing route lines, so the map more accurately traces the road path a vehicle actually takes. Adjacent duplicate locations are also no longer included, so back-to-back stops at the same location no longer produce redundant segments on the map.

Employee Shift Scheduling (v1 | Stable)

Group employee pairings by employee tag: We have added
groupByEmployeeTag
to employee pairings to ensure that employee pairings can be grouped based on a tag. This prevents Timefold from assigning employees to shifts at the same time but with different tags of the common tag type. When
commonTagType
is used without
groupByEmployeeTag
, employee pairings are valid if two employees work shifts at the same time with an identical tag of the common tag type. With
groupByEmployeeTag
defined, all pairings grouped by that tag will be valid only if all shifts worked at the same time have that identical tag of the common tag type. Certain employees may need to work at the same time (employee pairing), work the same type of shift (
commonTagType
), but also need to be grouped (
groupByEmployeeTag
). This feature makes it easier to define groups of employees with employee pairings.

Pick-up and Delivery Routing (v1 | Preview)

Improved solution quality: Timefold now favors nearby jobs both in construction heuristics and local search, producing better solutions with lower total travel time. In addition, jobs are more frequently pooled (if they allow it), leading to more efficient routes. However, if you do not want jobs to be pooled, be sure to set
prohibitJobPooling
to
true
for your jobs, as it will increase the construction heuristic speed.
Better visibility into travel efficiency and job pooling: The key performance indicators now include the average travel time per stop, as well as the percentage and absolute number of pooled jobs.

Please let us know if you have feedback.