Feature Requests

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.

We would like to have the ability for employee to apply priority level to Preferred timespans entered for a particular day. So if I prefer to work Shift A or Shift B or Shift C on a particular day, I prefer my first choice to be Shift A, second choice to be Shift C, and third choice to be Shift B. If there was an optional priority field (e.g. 1-5) to prioritize same-day preferred availability from an employee to favor if possible their higher choice for that day. Our workaround if this is not feasible would be to send duplicate preferred timespans for the ones they prioritized so the solvers rewards more.

Use-case: Currently, we set min-max per month etc that ties in to the employees FTE obligations to their department. And when FTE changes, we auto-update min/max, but this is cumbersome. It is even more tricky when one person's FTE change impacts everyone elses FTE. So wanted to suggest an alternative approach for future or if this is something you have solved previously. So, to play this out... Department FTE needs: 2.0 FTE Number of Employees: 3 Employee A: 0.75 FTE Employee B: 0.75 FTE Employee C: 0.5 FTE Employee C retires and the department is unable to hire a replacement. REACTION 1 : Department works short and Employee A and B's FTE remains unchanged. This one is easy we as we don't have to touch the min/max rules for those employees. REACTION 2 : Department needs to adjust Employee A and B's FTE to 1.0 FTE to cover the loss. This requires a re-update of all the min-max rules. Suggestion: Have an FTEDefinition object for what is 1.0 FTE per defined period: FTEDefinition: [ { "id": "1.0", "includeShiftTags": [], "period": "YEAR", "hoursPerPeriod": null, "shiftsPerPeriod": null, "daysPerPeriod": null, } ] And then Each employee object has a LIST field for their FTE obligations, each containing the FTEFraction and the associated FTEDefinition. This will allow an easy way to establish the baseline requirements and still allow us to capture more nuance with the existing period rules. Not sure whether would you translate the FTE obligation on the back end to to a HARD max and soft MIN?

"The employee contracts feature of Timefold allows to e.g. define maximum numbers of hours per day, or per week. These limits are for fixed timeframes. But certain labour laws, or company policies, or contracts might also have requirements for rolling time windows (e.g. maximum numbers of hours worked over a rolling time window of 48 hours). Such time windows can potentially also span longer than the planning window. This is a request to make that type of contract restrictions for rolling time windows possible."

For shift pairings / pairedEmployee, allow additional shifts to be selected (currently only one shift can be selected). For example, Anderson prefers to work with Brown when Anderson is working shift 1 and Brown on Shift 2. Currently, we can only select one shift and can't specify the shift order (i.e. if Anderson on this shift, then pair with brown, assigning brown to this shift. { "pairedEmployee": "BROWN", "onlyForShiftTags": ["Shift_1"] }

When sending input files with lots of pinned items, it is relevant to see how much the solver could fit on top of the already pinned items. With an extra column that shows the pinned items in the input this would put the assigned shifts (for Employee shifts) in perspective.

Some (not all) shifts can be rescheduled, date and/or time. I.e. ideally the shift is nov 11th, 10am-11am but if that is not possible, it may be rescheduled to nov 12th, anywhere AM or nov 13th 11am-12am. There can be an order of preferred alternatives, this can be a range or an exact slot. All the rules need to be configurable within the dataset, not global (difference groups have different rules). Potentially also the duration of a shift would be somewhat dynamic.

Currently, DST change works fine for shifts, but Employee has a static timezone offset used to interpret the period date spans start and end (e.g. start and end of a day). This works fine for multiple timezones but during a DST change, the Employee's offset should change according the time zone rules.

For continuous planning 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).