Stop SLAs, preferred areas, visit exclusions and more (v0.60)

Today, we’re announcing version v0.60 of the Timefold Platform and updates to the Timefold models.

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

Webhook logs
have been enhanced for events sent since the v0.60 release: they now include duration information (when available), and you can resend a webhook notification directly from the log by opening the event details.
This release also includes
various minor bug fixes
.

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

Field Service Routing (v1 | Stable)

Added soft constraint for a technician’s preferred area
: We have added a new soft constraint to define the preferred area of operation for a technician. Please see the Technician coverage area guide for more details.

Graphic showing two technicians and visits in their preferred service areas

Support pinning visits on a vehicle’s itinerary to a startServiceTime (Preview)
: Visits on a vehicle’s itinerary can now be pinned to a user-specified
startServiceTime
. This also permits the solver to modify the itinerary before and after the pinned visit (and not only after the pinned visit, as with the existing
pinningRequested
flag). To specify this, use the new
InputItineraryItem.pin
flag for a visit on your itinerary in combination with a
startServiceTime
on the same visit. Please refer to Pinning individual visits for further information.
Support for exclusion constraint between visits
: Visits can now be marked as mutually exclusive, preventing them from being assigned simultaneously in the same schedule. This is useful for scenarios where certain visits cannot be performed at the same time due to resource conflicts or business rules. See Changelog for details.
Improving the SLA constraint
: The SLA constraint has been improved to better handle visits that have a
latestSlaEndTime
defined, but remain unassigned in the solution. If a visit remains unassigned, but has a
latestSlaEndTime
defined before the end of the planning window, the model will now penalize the unassigned visit based on the end date of the planning window. Please see Visit SLAs for more details.
Speeded up the initialization and improved solution quality
by pruning the search space: We significantly increased the speed of attaining the first solution and improved the solution quality by pruning the search space using existing hard constraints.
Use case guide
: We have added a use case guide explaining common use cases for the Field Service Routing model and common challenges and recommendations for each of these use cases.

Employee Shift Scheduling (v1 | Stable)

Logged time for shifts
: The logged time for a shift can now be longer than the shift itself for occasions when employees work longer than planned. See the Minutes logged per period guide for more details.
Minimum weekends worked in rolling windows
: We have extended our weekend constraints support with the ability to assign weekend work in rolling windows. The Weekends worked in rolling window not in preferred range for employee constraint now allows you to also set a minimum number of weekends an employee has to work within a rolling window. For example, you can now express rules such as: “Minimum 2 weekends worked in any 4-week rolling window” or “Minimum 4 weekends worked in any 16-week rolling window”. This complements our existing weekend constraints, making it easier to set up rules to assign weekend shifts.

Pick-up & Delivery Routing (v1 | Preview)

Ability to define SLAs for stops
: You can now define a service level agreement (SLA) for stops. SLAs specify the preferred time the stop should be finished. This allows for more precise control over the scheduling of stops and helps ensure that service level agreements are met. Please see the Stop SLA guide for more details.
Additional performance improvements
: We have made additional performance improvements of the model by optimizing the use of constraints. This means you get higher quality solutions in much less time, enabling faster decision-making and improved productivity.
Openapi spec client generation: We have fixed some bugs in the openapi spec so that client generation based on this spec runs more smoothly.
Use case guide
: We have added a use case guide explaining common use cases for the Pick-up & Delivery Routing model and common challenges and recommendations for each of these use cases.

Please let us know if you have feedback.