Configuration overrides, per-employee disruption rules, co-located visit grouping, and more

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

With this release, the Timefold Platform reaches v1.0 - reflecting the stability and reliability it has been delivering to production customers for a while now.

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

Configuration overrides in submit, re-solve, and patch dialogs:
When submitting a new plan, re-solving, or patching an existing dataset, you can now specify configuration overrides directly from the UI dialog. This makes it easy to quickly experiment with small changes, e.g. disabling a specific constraint or tweaking a termination setting, without modifying your configuration profile. Overrides take priority over the values defined in the profile. The resulting configuration that will be applied can be validated on the dataset's configuration page. See the configuration documentation for more details.

Configuration overrides in New plan dialog

Solve queue priority in submit, re-solve, and patch dialogs:
When submitting a new plan, re-solving, or patching an existing dataset via the UI, you can now set the solve queue priority directly from the dialog.
Comparison UI improvements:
Move evaluation speed and move evaluation count are now also visible in the comparison UI.
Faster dataset detail page:
General speed improvements make the dataset detail page load more responsively.
Various bug fixes
, including a fix for configuration profile names containing commas breaking filter display, a redirect loop on login, and a display issue on the webhook log detail page.
New Helm chart for self-hosted installations
(self-hosted only): This release introduces a renamed Helm chart (
timefold-platform-selfhosted
, previously
orbit-platform
). If you self-host Timefold, a one-time update to your upgrade command is required to reference the new chart. See the v1.0.0 upgrade guide for details.

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

Field Service Routing (v1 | Stable)

New constraint to avoid unnecessary travel between visits
: Route optimization now includes the Prefer grouping co-located visits constraint (disabled by default), which encourages the model to assign visits with the same location into the vehicle shift's itinerary consecutively. As a result, the vehicle can perform these visits without traveling in between. See Prefer grouping co-located visits for more details.
Added the ability to set a maximum delay between dependent visits
: In addition to the existing functionality that allows specifying either a
minDelay
or a
minDelayTo
to delay a visit with a visit dependency, it is now possible to specify either a
maxDelay
or a
maxDelayTo
to limit the potential delay of such a visit. See Visit dependency with delay for further information.
Vehicle shifts can specify their own travel time adjustment
: Any vehicle shift can now specify its travel time adjustment, overriding the global
travelTimeAdjustment
from the model configuration. This enables you to express that a specific vehicle shift is faster/slower than another one.
OpenAPI schema inheritance fixes (output)
: The OpenAPI schemas for
OutputItineraryItem
hierarchy now include
allOf
referencing the parent schema. This enables client code generation tools to generate
VisitPlan
and
BreakPlan
as subclasses of
OutputItineraryItem
. As a result, instances of these classes can now be added into the
VehicleShiftPlan.itinerary
.

Employee Shift Scheduling (v1 | Stable)

Specifying weights for preferred and unpreferred timespans
: It is now possible to add weights for employee preferred and unpreferred timespans. This is useful when employees have a number of ranked preferences simultaneously, where one preference is more important than another. It can also be used to specify that one employee is of a higher priority when fulfilling preferences than another, by giving them a higher weight. The weight for each timespan is fully customizable. More information can be found in Employee preferred times, ranked.
Minimize disruption per employee
: You can now minimize disruption individually for each employee. This is configured using the new
disruptionRules
field in employee contracts. This is useful when the penalty for disrupting some employees is worse than for others, or when some employees have a penalty for disruption and some do not. Disruption is tracked by two separate constraints: "Minimize outgoing disruption per employee": penalizes when an employee loses shifts that were originally assigned to them, and "Minimize incoming disruption per employee": penalizes when an employee receives shifts that were not originally assigned to them. Each constraint has its own configurable weight (
minimizeOutgoingDisruptionForEmployeeWeight
and
minimizeIncomingDisruptionForEmployeeWeight
), allowing you to independently control the importance of disruptions for employees losing shifts or gain shifts during replanning.
Deprecation of global disruptionRules:
The
disruptionRules
field of the
globalRules
has been deprecated in favor of the contract-level
disruptionRules
. See migrating from 1.21.0 to 1.22.0 for more details on required configuration changes.
Tag based employee pairing
: Employee pairing has been extended to include tags. Employees can now be paired based on their ID or based on their tags. For more information, please see Pairing employees. This feature comes in handy when multiple people would be a good fit for pairing with a specific employee. For instance, a new employee Ann needs support whenever they get stuck. All employees with the tag "support" satisfy this requirement.
Breaks during shifts
: We have extended shifts to be able to define breaks. These breaks occur during the shift and don't count towards the time worked. For example, if an employee can only work eight hours a day and is assigned a nine-hour shift, then this will be penalized unless the shift has a break of at least one hour. For a more in-depth explanation and examples, see Shift breaks documentation and Labor law compliance scenarios with breaks. This feature can be useful if you have breaks during a shift that don't count towards the time worked.
Total cost output metric:
We have added an output metric
fixedTotalCost
that calculates the total cost of the schedule, based on the cost rules in the input dataset. For more information, see the cost management guide. This output metric makes it easier to calculate the total cost of the schedule based on the cost rules.
Skill expression validation:
We've fixed a validation issue when using complex skill expressions, which caused some of the inputs with multiple nested expressions to be rejected.

Pick-up & Delivery Routing (v1 | Preview)

OpenAPI schema inheritance fixes:
The OpenAPI schemas for
Break
and
OutputItineraryItem
hierarchies now include
allOf
referencing the parent schema. This enables client code generation tools to generate
FixedBreak
and
FloatingBreak
as subclasses of
Break
, and
StopPlan
and
BreakPlan
as subclasses of
OutputItineraryItem
. As a result, instances of these classes can now be added into the
DriverShift.requiredBreaks
and
DriverShiftPlan.itinerary
collections.
Pinning and fixing stops:
It is now possible to pin and fix stops in the Pick-up and Delivery Routing model. This provides more control over the scheduling of stops. It is particularly useful in real-time planning scenarios where the plan is already being executed. It is also useful in cases where certain stops must not be moved in the schedule. Please see the Pinning and fixing stops section for more details.

Please let us know if you have feedback.