Preferred time windows and waiting-time optimization for FSR, and smarter skill matching for ESS (v0.57.3)

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

This new version of the Timefold Platform includes minor UI improvements and bug fixes (like making sure that adding or removing users from a tenant is reflected in the UI immediately, cleanup of deprecated audit log types), and general stability improvements across the platform.

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

Field Service Routing (v1.15 | Stable)

Added preferred time windows for visits
: You can now specify preferred time windows for visits using the new
preferredTimeWindows
attribute. These preferred time windows allow you to express your preferences for when a visit should ideally be scheduled, without making it a hard requirement. If both a required time window and a preferred time window are specified the hard constraint will still schedule the visit during one of the provided required time windows, and the soft constraint will attempt to schedule the visit during an overlapping preferred time window. More details can be found in the preferred time windows guide.
Added constraint to penalize waiting times
: A new soft constraint “Minimize waiting time” has been added to the model to minimize the total waiting time in the schedule. By default, this constraint is deactivated. In order to activate it, minimizeWaitingTimeWeight needs to be set. In certain situations, the model produces a solution where a technician has to wait before starting the service at a certain visit. The waiting time occurs because there is a time window defined and the schedule happens to route the technician to arrive before the time window starts. In this situation, the technician has to wait before starting the service until the time window opens. The new constraint aims to minimize such waiting times. See the Route optimization guide for more details.

Employee Shift Scheduling (v1.15 | Stable)

Flexible skill matching strategies
: We have added support for flexible skill matching through the shift’s
requiredSkillsMatchKind
and
preferredSkillsMatchKind
fields. Two strategies are now available:
MATCH_ALL
(default): Employee must have all specified skills to be assigned to a shift.
MATCH_ANY
: Employee needs only one of the specified skills to be eligible for a shift. This feature provides greater flexibility in workforce scheduling, especially useful when multiple skill sets can accomplish the same task and/or you need to expand the pool of eligible employees for hard-to-fill shifts. See Skill matching strategies for more information.
Smaller improvements
: We have updated the optional shifts output metric to no longer be present in the output metrics if there are no optional shifts in the input. “Shift groups” and “shifts” are now treated separately in the output metrics to provide a more realistic view of how many shifts are assigned and unassigned. (See migrating from 1.14.0 to 1.15.0 for more details on the change.) And we have further improved the validation of the model. These changes help users catch and fix invalid datasets before solving. (See Improved validation for details.)

Pick-up & Delivery Routing (v1 | Preview)

Custom job priorities
: New "opt-1" to "opt-10" built-in optional job priorities have been added to the "1" to "10" built-in mandatory job priorities, making it possible to define the priority of optional jobs. In addition, it is now possible to define a custom priority and its weight. This gives the user finer control over the penalty of leaving a job unassigned. Please see Priority jobs section for additional details.

Please let us know if you have feedback.