Labels for the rule. Labels can be used to group rules together. For example, if multiple rules are related to the same shift type, they can all be labeled with the same label.
string (enum: NONE | VERY_LOW | LOW | MEDIUM | HIGH | ...)
required
The importance of the rule. The higher the importance, the more it will be taking the rule into account. Under strict importance, the rule may never be violated.
Filters to determine the scope of the rule. Used to indicate what the rule should be applied to (which employees, which shifts, etc). Leaving this empty means that the rule always applies.
Used to indicate how to apply the label filters. For example, if set to ANY, entities that have any of the specified labels will be included. Default: “ANY”.
Used to indicate how to apply the label filters. For example, if set to ANY, entities that have any of the specified labels will be included. Default: “ANY”.
List of days in the schedule. Each day will become one period. By default, each period will last the entire day. If a startTime and/or endTime are specified, these will apply to each period.
If true, the startTime and endTime will be applied to each individual day in the period. If false, the startTime will apply to the first day and the endTime will apply to the last day. Default: false.
The number of days between the start of each period. If not specified, this defaults to the value of daysPerPeriod, creating non-overlapping consecutive periods. Setting daysBetweenStarts to 1 will create a sliding window of periods.
If true, the startTime and endTime will be applied to each individual day in the period. If false, the startTime will apply to the first day and the endTime will apply to the last day. Default: false.
Within the context of this rule, a period is considered ‘worked’ for an employee if they work any shift during that period, and
‘free’ if they do not. The rule allows you to set targets for how many periods an employee can work, how many they can work in succession,
and how many free periods they must have surrounding a working period.Often seen use cases are the distribution of weekends, holidays, or other inconvenient periods among employees.
An easy use case is to limit how many worked periods an employee can have.
The rule below makes it undesirable for employees to work more than 2 weekends. Notice that working a shift is only considered
as working a period if it overlaps for at least 6 hours with the period, as configured in options.overlapSettings.To work with labels on periods, make sure you have defined the period label in the extensions.labeling part of the payload.
Alternatively, the rule can be used to encourage a minimum amount of worked periods for an employee.
The rule below sets a target for the minimum number of weekends during which the employee works any shift.
minWorkedPeriods is never treated as a strict lower bound, but rather as a target that the solver will try to reach.
Alternatively, the rule can be used to limit how many undesirable periods an employee can work in succession.
The rule below makes it strictly forbidden for an employee to work 3 holidays in a row. Notice that with the way periods are defined,
working both days of Christmas still only counts as working one period. If the days of Christmas should count as working separate holidays,
you would need to define them as separate periods.
The rule can also be used to enforce a minimum number of free periods surrounding a worked period.Note that it is currently not supported to use the minSurroundingFreePeriods property in combination with the maxConsecutiveWorkedPeriods property.
The rule below makes it strictly required for an employee to have at least 1 free weekend surrounding each worked weekend.