Feature Requests

This request is to allow configuring traffic impact on various dimensions (time, region etc) to adjust expected travel time for known traffic impact.

Some runs terminate during their construction heuristics phase (where the first solution is being searched). Construction heuristics typically finish in seconds, but there are datasets where this takes longer, and the termination limit kicks in. Today these runs have status “complete” in the platform & UI. But if you dig into the logs of the run, you see that the local search phase of the solver didn’t start yet. If the construction heuristics did not fully finish, the results of such a run will be incomplete (it will not contain all entities), and associated metrics will also not be taking into account the full submitted problem. As such, it’s important information to decide how to use the results of the run. This is a request to add a new status “Incomplete” in the platform so these types of runs are easily distinguishable from runs where construction heuristics did finish, and the local search phase was started, and optimization ran.

This is a request for Timefold to become ISO 27001 certified.

This is a request for Timefold to become SOC 2 certified.

The score calculation speed should never differ for more than 10% for the exact same dataset (with the same configuration with the same versions). This is probably due to Noisy Neighbors. In which case, the fix is sole tenants or Bare Metal (for Premium accounts, as it affects Timefold's operating costs).

Data should not cross the border (hippa, GDPR, ...). Reduce latency The api's should run per region. But the management across regions should happen from app.timefold.ai . Think mongo's geo support etc.

This is a request to make it possible to define shifts where one of a list of skills is required. It would be good if the required skills can be also be OR . So if I have two different skills but an employee has to have one of them. Today you can put in more than one skill but then it requires both of them.

The current implementation penalizes a non-matching skill by the number of minutes that a shift is not covered by a required|preferred skill. Equina needs to support the use-case when an employee is required|preferred to have a skill only to start a shift (not for the whole shift duration):

We're asking to include the rule ID for the recommendation API (i.e. the API that makes the recommendation of the next best employee that can be assigned to the shift). Currently, the recommendation api only shows the rule category, not the individual rule. We would like to see the individual rule included in the recommendation API. E.g. if you have configured multiple periodRules, we would like to see the recommendation API output constraint diffs per rule, and not only aggregated. Similar like the justifications do.

Some jobs require (limited) equipment or tools to be used while executing a task. Some task also require spare parts to be taken along. Given that the number of tools is finite, this introduces an additional constraint to the optimisation process, ensuring that tool availability is factored into production schedules. Potentially that equipment needs to be cleaned or charged in between use.