New and noteworthy

A missing skill or tag in an input dataset was penalized as -1hard resulting in a much smaller penalty than, for example, violating the maximum service end time of a visit.

As a result, an infeasible solution that broke a skill or tag requirement was favored over an infeasible solution with all skills/tags but that didn’t finish the service in time by a couple of minutes.

The following hard constraints weights were rebalanced: Require skills, Require tags and Require vehicles.

When submitting a recommendations API request, you can specify an optional boolean includeJustifications query parameter to control whether constraint match justifications should be included in the response.

This is useful for getting more fine-grained information about the constraint matches, for instance to learn which visits are not completed in time because of the recommended visit (or visit group) assignment.

Please see the Visit time window recommendations and Visit group time window recommendations guides for more details.

We have added a custom move to facilitate movable visits assignment.

Previously, a movable visit could have blocked the assignment of another visit, resulting in the model not being able to assign all visits. The new custom move reassigns the movable visit, increasing the chance of assigning all visits.

We have added 6 new input metrics that provide information on the dataset input:

See OpenAPI Spec for a description of their meaning.

We have improved memory usage efficiency, resulting in better scalability over datasets with large numbers of visits.

A new set of KPIs has been added, please see the Key Performance Indicators section for details:

Similarly to the model run, the recommendation calls now validate the input dataset.

Every vehicle shift can specify a Vehicle Shift Cost that will be used in the optimization by the minimize shift cost constraint. Please see the Technician costs guide for details.

We have added a new KPI representing the total cost of the solution.

We have improved the Visualization UI, with better formatting of dates and coordinates as well as improvements to the color scheme.

We have implemented minStartTime, maxStartTime, and maxEndTime to replace the now deprecated startTime and endTime. Adding maxStartTime opens the possibility to get recommendations for fixed-start visits (these are visits where minStartTime equals maxStartTime).

We have added a capability to specify preferred vehicles for a visit. When set, the visit can be assigned to a shift of one of the specified vehicles if possible. You can specify these as modelInput.visits[].preferredVehicles when submitting a new route-plan. Refer to the OpenAPI Spec for details.

We have added activeDateTime and shutdownDateTime attributes in model run information.

We have added a new KPI for the fairness constraint that we introduced with v0.30.0. See the feature guide for fairness or the Timefold Platform UI for a description of its meaning.

We have enabled multi-threaded solving for this model. Based on our benchmarking results, the maximum number of threads is limited to 4 for now.

The desired maximum number of threads can be specified by the maxThreadCount attribute in Run configuration. The default is 1.

We have added a new constraint to the model that allows you to balance the workload fairly across technicians based on their time worked. The constraint also allows for historical data to be considered. This can be useful when you want to balance the workload fairly based on past hours worked by the technicians.

More information can be found in the feature guide for fairness.

Priority is now defined as a number between 1 and 10 (both included), with 10 being the lowest priority and 1 being the highest priority. The default priority is "6".

Please see Upgrading to the latest versions for additional details.

Added includeDependencies as a new parameter to the VisitTimeWindowRecommendationRequest API. With this parameter you can select whether you want to check for possible dependent vehicle shift plans that might be influenced by a recommendation. If the recommendation for a visit puts it before other visits, it might change the arrival, start of service and departure times of the previously planned visits. If those have relations to other visits (e.g. visit groups, visit dependency), the recommendation might also affect other vehicle shift plans. By setting the includeDependencies parameter to ALL, these dependencies will be part of the response.

We have replaced the existing demo datasets with new ones that are more realistic and better showcase the model’s features.

The new demo datasets cover basic Field Service Routing capabilities, Visit Dependencies, and Visit Groups.

Added minStartDateAdjusterIncrement to the minDelayTo VisitDependency. The value determines how many times the minStartDateAdjuster is applied. This allows a more precise control over the delay.

More information can be found in Dependencies between visits under Visit dependency with minimum delay as a point in time

Added capability to specify vehicles required by a visit. When set, the visit can be assigned only to a shift of one of the specified vehicles. More information can be found in Visit assignment restrictions.

Added VisitDependency capability to specify additional conditions between dependent visits, such as requiring both visits to be assigned to the same vehicle (not the same vehicle shift). More information can be found in Visit dependency with coordination.

When defining Visit Groups, you can now specify they need to be aligned at the end of the Visit. You can use this if two or more technicians need to be present for a Visit at the end of the job. E.g. both technicians need to be present to finish the task after preparation work was done by one of them.

More information can be found in Visit Group reference.

Added VisitDependency capability to specify a delay to the next day/week/day-of-week, more information can be found in Visit dependencies.

0.20.0 is backward compatible with 0.19.0 and no migration is required.

Fixed validation of all model input date-time attributes to require the time zone offset.

Validation now rejects a vehicle without any vehicle shifts.

0.19.0 is backward compatible with 0.18.0 and no migration is required.

All ISO 8601 "Local date time (unqualified)" types have been replaced by ISO 8601 "Local date time with offset to UTC" (Coordinated Universal Time) to support multiple time zones.

Please see migrating from 0.17.0 to 0.18.0 and Time zones and daylight-saving time (DST) for additional details.