Skip to main content

Continuity Constraint

Soft constraint*

* with possibility for hard constraint

The continuity constraint can be enabled to improve the continuity of selected employees for certain shifts. This can be relevant in cases where planners want to make sure that they do not have to onboard new employees every day (when employing temp workers), or where it is preferred for employees to work multiple shifts in similar groups.

The constraint is configured by specifying continuityGroups. A group consist of one or more shifts, and can be specified to apply to the entire schedule (default) or to a certain set of days.

The solver will attempt to ensure that all shifts within one continuityGroup are worked by the same employees. If this is not possible, it will try to minimize the number of deviations.

Each continuity constraint can be assigned a weight from 0 to 100 to indicate its importance. Moreover, should a planner require strict continuity for some continuityGroup, the isStrict property can be used.

Strict continuity​

A group is considered to have strict continuity when all shifts in the group are worked by the first X entries in some ordering of all employees. The number of employees (X) may differ per shift. For instance, this is an example of assignments that would constitute strict continuity. The numbers represent employees.

Monday    | [8, 3, 2]
Tuesday   | [8, 3, 2, 5, 7]
Wednesday | [8, 3, 2, 5]
Thursday  | [8, 3, 2, 5]
Friday    | [8]
Payload example

The following example shows two continuity constraint with three continuity groups in total, which have the following effects:

  • It is preferred to have a similar group of people working all shift-1 shifts during the first week.
  • It is preferred to have a similar group of people working all shift-1 shifts during the second week. This may be a different group than was used in the first week.
  • It is required for all shift-2 shifts to be worked by the same group of people. This applies to the entire schedule.
{
  "continuityConstraints": [
    {
      "id": "cc-123",
      "continuityGroups": [
        {
          "shiftIds": ["shift-1"],
          "scheduleDays": {
            "dayIndexes": [0, 1, 2, 3, 4]
          }
        },
        {
          "shiftIds": ["shift-1"],
          "scheduleDays": {
            "dayIndexes": [5, 6, 7, 8, 9]
          }
        }
      ]
    },
    {
      "id": "cc-456",
      "isStrict": true,
      "continuityGroups": [
        {
          "shiftIds": ["shift-2"],
        }
      ]
    }
  ]
},
Continuity Constraint in the request payload
id
required
string (constraintId)

The id of the constraint should be UNIQUE in the context of constraint type.

weight
integer (constraintWeightPositive) [ 0 .. 100 ]

Describes how much the constraint is taken into account when solving the schedule. The higher the value, the more solver will penalize the constraint violation. None of the weight values make it a hard constraint - even when weight is set to 100 it is not guaranteed that the constraint will be satisfied. The weight value is relative to other constraints.

isStrict
boolean
Default: false

If set to true, continuity groups in this constraint must have strict continuity. A group is considered to have strict continuity when all shifts in the group are worked by the first X entries in some ordering of all employees. The number of employees (X) may differ per shift. For more information, see the Continuity Constraint documentation.

If a shift impacted by this constraint cannot be filled without breaking strict continuity, it will remain unassigned.

required
Array of objects non-empty

Groupings of shifts which should preferably be handled by a low number of distinct employees. Currently, a shift can only be part of one continuityGroup per continuityConstraint.

{
  • "id": "string",
  • "weight": {
    },
  • "isStrict": false,
  • "continuityGroups": [
    ]
}