Configurable justifications in Recommendation APIs for both models, tag exclusion filtering and several other improvements (v0.37.0)

Today, we’re announcing version v0.37.0 of the Timefold Platform and models, including improved timeline and statuses for each model run.

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

Support for excluding runs with certain tags when filtering
: When filtering the run overview, you can now choose to exclude runs with a certain tag. This gives you greater flexibility in finding and comparing certain runs. (E.g. you could label any simulation runs with a tag, and then exclude it when you want to look at only production runs.)
Tenant Members with expiry date
: It’s now possible to give people temporary access to your tenant by setting an expiration date when adding/editing the members of your tenant. Use this to e.g. give our customer support team temporary access to your tenant for troubleshooting.
Self-hosted platforms are now single tenant
: We’re limiting the ability for self-hosted platforms to create additional tenants. We’re doing to limit the complexity and recommend customers that self host to have multiple installations of the platform instead. More details about self-hosting the Timefold Platform versus using the Timefold Cloud Platform can be found in this comparison guide.
Rework of run policies
: We have reworked the policy limiting the amount of simultaneous runs to check simultaneous threads instead. When you have e.g. 10 simultaneous threads available in your plan, you can use it to do 10 simultaneous runs each using 1 thread, or do 5 simultaneous runs each using 2 threads. We have dropped the policy that checks the maximum runs per hour.
We have updated the documentation to more clearly explain the different statuses of a run.
Smaller bugfixes (including using the configuration profile from the run when calling the score analysis API endpoint).

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

Employee Shift Scheduling (v1 | Stable)

Configurable justifications in the Recommendations API
: 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 period rule is violated by the recommended employee assignment. See New and noteworthy for details.
Priorities on Contract Rules
: Priorities have been added to contracts. This means some contracts can now have higher priority than others. This feature allows for granular control over how much contracts comparatively weigh in solutions. It comes in handy when there is a contract that defines a certain rule that is more important than another, e.g. Contract A defines rules related to period which are more important than Contract B’s rules related to minimum time between shifts. See New and noteworthy for details.
Maximum number of unique tags per period per employee
: We have introduced 2 new constraints to limit the number of unique tags that can be used to assign shifts to employees. You can use this feature to limit the amount of shift types, routes or skills that will be assigned to an employee. See New and noteworthy for details.
Significant speed improvements for bigger datasets
: By pre-calculating matching rules and shifts we were able to improve the performance of datasets using global rules. We’re seeing improvements anywhere between 10% and 50%.
Several documentation updates, including new feature guides explaining Alternative shifts, Shift travel and locations, and Shift rules.
Smaller improvements (e.g. to the demo data sets) and bugfixes.

Field Service Routing (v1 | Stable)

Configurable justifications in the Recommendations API
: 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. See New and noteworthy for details.
Smaller improvements (e.g. to the demo data sets and the visualization UI) and bugfixes (e.g. to the termination limit not always being respected).

Please let us know if you have feedback.