Disrupted employees KPI in ESS, all-or-nothing co-located visits in FSR, notifications as the one place for webhooks, and more

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

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

Set up webhooks and read their logs in one place: Notifications
: Notifications is now the only place to set up webhooks, with a webhook channel, and to read their logs. The retention period for the logs of the old webhooks has ended, so we removed the read-only
Webhooks
pages from
Manage tenant
. See webhook channel and logs for more details.
Email when someone declines your tenant invite
: You now get an email when someone declines your invite to join a tenant. See Invite a new member to a tenant for more details.
Failed notification emails include the error and tenant name
: When a notification channel fails after all its retries, the email to the tenant administrators now includes the error and the tenant name. See Retry strategy for more details.
Ask Claude or ChatGPT about any documentation page
: Every documentation page now has
Ask Claude
and
Ask ChatGPT
buttons above the table of contents. Each opens that assistant in a new tab with a prompt to summarize the page.
The secrets list shows all your secrets
: The secrets list now shows every secret, 50 per page, instead of only the first 100. Search and the secret pickers in the notification settings cover every secret too. If loading fails, the list shows an error instead of appearing empty.
Patch plan works without overrides
: The
Patch plan
dialog no longer fails with "$.config: must have at least 1 properties" when you patch a plan without overrides.
Configuration profiles save after changing a parameter without a constraint weight
: A configuration profile no longer fails to save after you change a model parameter that has no constraint weight.
Dates and times always show in your time zone
: Dates and times, for example in the plans list and the configuration profiles list, now always show in your time zone, including after you reload a page.

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

Employee Shift Scheduling (v1 | Stable)

See how many employees replanning disrupts
: The
disruptionPercentage
KPI shows how many shifts replanning changes. Managers also need to know how many people replanning affects. The
kpis
object now includes the
disruptedEmployeesPercentage
KPI, with the title "Disrupted employees", to show this. An employee is disrupted when they lose a shift that was originally assigned to them. An employee is also disrupted when they get a shift that was originally assigned to someone else, or that was not assigned. The KPI is the percentage of disrupted employees among the employees with at least one shift in either the existing schedule or in the new schedule. The "Disrupted employees" KPI replaces the "Disruption percentage" KPI in the default KPI view. The "Disruption percentage" KPI is still available under
Show all
. See Key performance indicators and Real-time planning for more details.
New lessons: apply rules to some shifts and plan around absences
: Some rules don't apply to every shift, for example at most five night shifts worked in four weeks. Lesson 6: Treating shifts differently continues the lesson series and shows how to use tags and tag types to apply rules to a subset of shifts with
includeShiftTags
and
excludeShiftTags
, followed by a practical example. Employees aren't always available to work, for example during a vacation or parental leave. Lesson 7: Planning around absences shows how to plan around required absences with unavailable or available time spans, and how to combine them with shift tags, followed by a practical example. See Lesson 6: Treating shifts differently and Lesson 7: Planning around absences for more details.
Visualization keeps your view while the model solves
: You can now inspect part of a schedule while the model solves, without the view jumping back each time a new solution arrives. This release also includes smaller visualization improvements, for example employees with a shift in the selected dates now appear first in the
By employee
view, and pinned shifts show the pin icon even when the shift block is narrow. See Visualization for more details.
Consistent matching for empty tag lists in daily shift pairings and rotation groups
: In daily shift pairings and shift rotation groups, an empty tag list with
shiftTagMatches
set to
ANY
matched no shifts. It now matches every shift, the same as with
ALL
. This can change the score of existing schedules. A
WEEKLY
rotation group with
ANY
and no
includeShiftTags
that the model accepted before can now fail validation with
SHIFT_MATCHES_MULTIPLE_ROTATION_GROUPS
. See daily shift pairings and shift rotation groups for more details.
Incomplete or duplicate cost details no longer stop the dataset from solving
: In costs rules, an
employeeShiftCostDetails
item without
employeeCostGroup
or without
cost
caused an error before solving started. Two items with the same
employeeCostGroup
and
shiftCostGroup
caused the same error. The model now ignores items without
employeeCostGroup
or
cost
, and uses only the first item for a repeated pair of cost groups. Validation reports each case with a warning:
COSTS_RULE_COST_DETAIL_MISSING_EMPLOYEE_COST_GROUP
,
COSTS_RULE_COST_DETAIL_MISSING_COST
, and
COSTS_RULE_COST_DETAIL_DUPLICATE_COST_GROUP_PAIR
. See costs rules for more details.
Global period and costs limits now respect shifts already worked
: Global
minimumMaximumShiftsPerPeriod
rules and global
costsRules
now take into account the shifts already worked earlier in the same period, so the plan no longer exceeds limits such as a maximum number of shifts per week or a maximum cost per pay period. The
shiftsWorkedMin
,
shiftsWorkedMax
, and
uniqueTagsLimit
fields of global rules, and the
totalCostsMin
and
totalCostsMax
fields of global
costsRules
, now count every assigned shift in each period that overlaps the planning window, including when the shift ends before the planning window
start
(a historic shift) or starts after its
end
. This matches how contract period rules already count these shifts. See Historic shifts and the upgrade guide for more details.

Field Service Routing (v1 | Stable)

Stricter checks for overlapping shifts of a vehicle
: A vehicle can work only one shift at a time. Validation now gives the warning
VEHICLE_SHIFTS_OVERLAP_ISSUE
when two shifts of the same vehicle overlap. The issue detail gives the vehicle ID, the IDs of the two shifts, the end time of the first shift, and the start time of the second shift. Previously, the model checked overlaps only for shifts in the same linked shift, and only when both shifts set
maxEndTime
and
minStartTime
. Other overlaps were accepted without a warning, so the model could plan the same vehicle in two places at the same time. A shift starts at
minStartTime
(or
minFirstVisitArrivalTime
) and ends at
maxEndTime
(or
maxLastVisitDepartureTime
). If it sets no end time, it ends at midnight at the end of its start day, the same default the model uses when solving. The
LINKED_SHIFTS_OVERLAP_ISSUE
check for shifts in a linked shift now uses the same rules and stays an error. Input with linked shifts that the model accepted before can now fail validation. For example, two shifts in the same linked shift on the same day with no end time now fail, because the first shift ends at midnight, after the second shift starts. To fix this, set
maxEndTime
or
maxLastVisitDepartureTime
on each shift so that it ends before the next shift of the vehicle starts. See Upgrade from 1.38.0 to 1.39.0 and Input validation for more details.
Assign co-located visits all together or not at all (preview)
: When several visits at the same location must be completed in a single trip, partially serving the location isn't helpful. Previously, you had to link such co-located visits with visit dependencies yourself, using
SAME_SHIFT_ENFORCE
coordination and a restricted pooling type. The new
modelInput.allOrNothingScope
setting, set to
COLOCATED_VISITS
, now makes the model create these visit dependencies for you. Visits at the same location, or within
preferGroupingColocatedVisitsRadiusMeters
of each other, are then either all assigned to the same vehicle shift, one right after another, or none of them is assigned. A visit can be excluded with
excludeFromAllOrNothing
. This feature is in an early preview state and may have limitations or be subject to change. See All-or-nothing for co-located visits (preview) for more details.

Please let us know if you have feedback.