Feature Requests

Each Timefold tenant has limitations on the amount of concurrent threads that can be used by the tenant. This is defined by the tenant's plan. When the maximum is reached, today the platform rejects new runs, and it's on the API end user to retry later. This is a request for the platform to allow to queue further runs, that then start when there are again threads available.

For real-time replanning use cases it would be very helpful if you can refer to an existing plan (run) and only have changed data elements in the input instead of the complete input payload (e.g. new visits to take into account for Field Service Routing, a sick employee for Employee Scheduling).

This is a request for a "reality check" comparison feature, that makes it possible to compare optimized plans (made in advance) to the plans that were actually executed. The idea would be that this shows: How often, and in what ways, reality deviated from the plan (e.g. delays, reassignments). Whether the plan was too rigid, and where introducing more flexibility could improve real-world outcomes.

This is a request for the Timefold Platform to easily tweak the problem statement of a planning problem and run simulations on how the plan would like like under different other scenario's. Possible what-if scenarios to explore could be: What if I add 20% more workload? What if I have 3 more employees available with certain skills? What if lunch breaks would be 10 minutes longer? The request is to make it possible to: Easily tweak the problem statement (ideally using no-code tools); Run the experiment (in a sufficiently representative way) Be able to easily compare the results

This request is to make available reporting capabilities in the Timefold Platform that expose bottlenecks or inefficiencies in runs of a model. The report could focus on: Which constraints limit the solution the most Which tasks/visits/shifts stay unassigned, and information on which segments they belong to (to e.g. find skills that are missing the most); Which tasks/visits/shifts are hard to plan (based on indictment information)

This request is to make it possible to submit a planning problem (e.g. an employee roster, or a routing plan) as a static plan. The plan doesn't need to be further optimized, but the run should be: scored (constraint scores, etc.) have computed input & output metrics The run should be distinguishable from other optimized runs. The use case of this is so that you can then: compare the reference run to other runs via https://feedback.timefold.ai/feature-requests/p/ability-to-compare-kpis-and-statistics-from-different-runs have the same metrics computed by Timefold as for other runs

Snowflake is a cloud-based data platform that enables organizations to store, process, and analyze large amounts of data. An integration between Timefold and Snowflake can be useful for getting the data from external systems transformed to the input needed for a Timefold Model Run, but can also be useful to connect the Timefold Model Run output back to customers' Snowflake installations.

This is a request to make it possible to export the output of a model run to spreadsheet format ( .csv or Excel), to be able to share the output with the rest of the business to validate & spot-check the plan. Today only an option to download the .json is available.

A model run can finish for a couple of reasons: error/problem maximum termination time reached no more (significant) improvement found in last timeframe While the status of a run reflects the difference between successful, failed and incomplete runs, there is no distinction between successful runs that terminated because the time limit was reached or because there has not been a significant improvement. It would be good if the platform UI could help distinguish that.

Imagine a scenario where 3 visits need to happen at the same location. Each visit would take about 15 minutes (some preparation, the task, evaluation). But if you would do them together, the total time of doing all 3 together might be shorter than 3 times 15 minutes. This is a feature request for the Field Service Routing Model to support automatic collapsing of visits in such scenarios.