Feature Requests

This is a request to be able to configure minutes-between-shifts rules for sequences longer than two back-to-back shifts. Currently, the maximum sequence length is capped at two, which prevents defining rules such as requiring at least 36 hours off after a sequence of four night shifts. Allowing longer sequences would provide more flexibility in planning and ensure adequate rest periods for extended consecutive work periods.

This is a request to make disruption rules more employee-focused. Currently, global disruption limits (e.g. allowing 1% of shifts to be changed) can still result in uneven outcomes; some employees may experience many disruptions while others are unaffected. Customers would like the ability to minimize or cap disruptions on a per-employee basis, ensuring changes are distributed more evenly. Possible approaches include balancing disruptions across employees or setting a hard limit (for example, allowing no more than 50% of an employee’s shifts to be disrupted). This would better support “human-centric” planning practices.

This is a request to be able to submit a tally of historic shifts instead of passing all historic shift data to the model. This would reduce payload size and memory usage while still allowing constraints (such as period rules) to consider past shifts. The goal is to improve efficiency and simplify input data handling where full historic data is not required.

This is a request to be able to assign customizable weights to different contract rules, similar to how weights can be set for multi-day pattern rules. This would allow more important rules (such as vacation constraints) to carry higher penalties, ensuring that critical preferences are respected during planning.

This is a request to allow the planner to consider certain skills as required or preferred only at the start of a shift, rather than for the entire shift duration. Currently, non-matching skills are penalized based on the total minutes an employee lacks the required skill during a shift. This is a request to also support cases where an employee’s skill is only necessary to start a shift.- for example, when shifts are scheduled in monthly blocks. In these cases, employees may still be responsible for covering late-night shifts that extend past the end of the month, even if their skill validity technically ends earlier. Supporting “start-of-shift” skill requirements would ensure these assignments are handled correctly.

This is a request to add support for a built-in YEAR period in the ESS model, similar to the existing DAY, WEEK, and MONTH periods for certain rules. Currently, only shorter periods than YEAR are supported.

All options to specify pairings now require users to provide references to specific employees to pair with. There are scenarios where it would make sense to also allow for pairing based on the tag of the employee.

Demand-curve based scheduling is now an established feature in our model. However, to use it, the user must manually create shifts for the day, and the solver chooses which shifts to assign in order to best meet the demand curve. This request is for the solver to create the shifts itself as part of the demand curve scheduling. So if the input contained the employees and their contracts as well as the demand curve for each day, then the solver would create and assign the shifts to best staff the demand curve. The output would be the newly created shifts and the employees assigned to them. This is a long-term request based on conversations with multiple prospects and clients, most notably Factorial and most recently Tanda. It's something that's been coming up more and more often recently in prospect conversations.

This is a request to make validation errors returned by the ESS model structured and machine-readable. Currently, error messages are text descriptions that vary in format depending on the error type, making them hard to parse programmatically. Customers would like identifiers (e.g. the IDs of the objects causing the error) and other relevant details to be available as separate fields in the error object, instead of being embedded in human-readable strings.

This is a request to make it possible to define a daily demand, so it's possible to configure requirements like: "Everyday we need at least 1 employee with skill X"