> ## Documentation Index
> Fetch the complete documentation index at: https://docs.automaticrostering.visma.net/llms.txt
> Use this file to discover all available pages before exploring further.
# Pattern
> Define desired or undesired shift patterns.
export const PatternMetricRows = () => <>
PATTERN.DESIRED_COMPLETE_MATCHES | Number of periods that completely match a desired pattern. |
PATTERN.DESIRED_PARTIAL_MATCHES | Number of periods that partially match a desired pattern. |
PATTERN.DESIRED_INCOMPLETE_PERIODS | Number of periods that do not completely match a desired pattern. |
PATTERN.UNDESIRED_COMPLETE_PERIODS | Number of periods that completely match an undesired pattern. |
;
Pattern can be used to specify patterns that are desired or undesired for the employee to follow in the produced roster. Both possible use cases are discussed separately below.
Used to define patterns of shifts that employees should follow or avoid.
Unique identifier for the rule.
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.
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.
If set to true, we will try to make employees follow the specified patterns. Else, we will try to avoid making employees follow any of the specified patterns.
Filters to determine the scope of the rule. Used to decide which employees the rule should be applied to.
Used to filter which employees the rule should be applied to. If not specified, the rule applies to all employees.
List of employee ids that the rule should be applied to.
List of employee labels that the rule should be applied to.
Used to indicate how to apply the id filters. For example, if set to NONE, entities with the specified ids will be excluded. 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".
Additional options for how the rule should be applied.
Describes whether the pattern should skip over days that could be considered irrelevant for the pattern.
Describes whether the pattern counts days outside the schedule period as days in the pattern. The pattern can either always include them (INCLUDE), skip over them (EXCLUDE) or only include them if the pattern allows for a day off on that day (MATCH). Takes priority over the dayWithoutDemand and dayOff properties. Default: "INCLUDE".
Describes whether the pattern counts days without demand as days in the pattern. The pattern can either always include them (INCLUDE), skip over them (EXCLUDE) or only include them if the pattern allows for a day off on that day (MATCH). Default: "INCLUDE".
Describes whether the pattern counts days off as days in the pattern. The pattern can either always include them (INCLUDE), skip over them (EXCLUDE) or only include them if the pattern allows for a day off on that day (MATCH). Default: "INCLUDE".
List of periods in the schedule. Periods can be defined explicitly or through a recurrent definition (for example, to generate weeks).
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.
List of dates in the schedule. Only allowed in CALENDAR payloads.
List of day indices in the schedule. Only allowed in RECURRING payloads.
List of days of the week. Will apply to all days in the schedule that match any of the specified weekdays.
TIME ISO 8601 format hh:mm. Equivalent to the 24h format of a single day. Use 00:00 to represent midnight.
TIME ISO 8601 format hh:mm. Equivalent to the 24h format of a single day. Use 00:00 to represent midnight.
List of custom period definitions. Each custom period definition defines one period in the schedule.
Describes one day in the schedule.
Date specified in ISO8601 format (YYYY-MM-DD). Only available in CALENDAR schedules.
Day index relative to the horizon start day (starts at 0). Only available in RECURRING schedules.
Describes one day in the schedule.
Date specified in ISO8601 format (YYYY-MM-DD). Only available in CALENDAR schedules.
Day index relative to the horizon start day (starts at 0). Only available in RECURRING schedules.
TIME ISO 8601 format hh:mm. Equivalent to the 24h format of a single day. Use 00:00 to represent midnight.
TIME ISO 8601 format hh:mm. Equivalent to the 24h format of a single day. Use 00:00 to represent midnight.
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.
A recurrent definition to easily create a set of similar periods.
The number of days in each period.
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.
Describes one day in the schedule.
Date specified in ISO8601 format (YYYY-MM-DD). Only available in CALENDAR schedules.
Day index relative to the horizon start day (starts at 0). Only available in RECURRING schedules.
Describes one day in the schedule.
Date specified in ISO8601 format (YYYY-MM-DD). Only available in CALENDAR schedules.
Day index relative to the horizon start day (starts at 0). Only available in RECURRING schedules.
TIME ISO 8601 format hh:mm. Equivalent to the 24h format of a single day. Use 00:00 to represent midnight.
TIME ISO 8601 format hh:mm. Equivalent to the 24h format of a single day. Use 00:00 to represent midnight.
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.
Provide labels to re-use periods that were defined in the configuration.
The patterns that should be followed or avoided.
Defines the pattern that should be followed. Each element in the array represents a day in the pattern. Note that DAY\_OFF is not allowed on strict undesired pattern rules.
Used to filter which shifts the rule should be applied to. If not specified, the rule applies to all shifts.
List of shift ids that the rule should be applied to.
List of shift labels that the rule should be applied to.
Used to indicate how to apply the id filters. For example, if set to NONE, entities with the specified ids will be excluded. 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".
A keyword to represent that a day must be a day off (DAY\_OFF), must be a worked day (ANY\_SHIFT), or that there are no requirements on this day (ANY).
List of days in the schedule.
List of dates in the schedule. Only allowed in CALENDAR payloads.
List of day indices in the schedule. Only allowed in RECURRING payloads.
List of days of the week. Will apply to all days in the schedule that match any of the specified weekdays.
Used to apply the rule only to work carried out in specific roles.
List of relevant role ids.
If set to true, each instance of the pattern will be repeated from its start day until the end of the period that the instance falls within. Otherwise, the pattern is not repeated. Default: false.
The offset that the pattern may start with on the start day. If set to 0, the pattern must start with the first pattern day on each start day. If set to 1, the pattern may start from any of its pattern days on the start day. If set to 7 (for example), the pattern may start with every 7th pattern day on the start day. The pattern is then continued as usual. Default: 0.
## Undesired patterns
For undesired patterns, simply define the patterns that you would not want employees to follow. By default, the solver will try to never assign shifts to employees that would make them follow the undesired patterns.
However, if you so desire you can use the `startDays` field on a specific pattern to specify that the pattern should only be avoided at specific times. For example, some patterns might be fine to follow during the week, but only become undesired during the weekend.
The rule below makes it undesirable for employees to work the night shift on both Saturday and Sunday.
```json theme={null}
{
"id": "spc-weekend-patterns",
"importance": "MEDIUM",
"isDesired": false,
"patterns": [
{
"startDays": {
"daysOfWeek": ["SAT"]
},
"patternDays": [
{
"shifts": { "ids": ["night-shift"] }
},
{
"shifts": { "ids": ["night-shift"] }
}
]
}
]
}
```
When the [importance](/v2/rules/index#rule-importance) of a pattern rule is set to `STRICT`, the solver will *never* make an employee follow the specified pattern. Since this cannot be guaranteed with respect to days off, it is not allowed to use the keyword `DAY_OFF` within a strict undesired rule's pattern.
## Desired patterns
The desired version of this rule works in a similar way. Define the patterns that you would like employees to follow. By default, the solver will try to assign shifts to employees that would make them follow the desired patterns.
However, if there are multiple patterns that you would like the solver to choose from, some further configuration is needed. In this case, it is required to define `periods` on the rule. Within each defined period, the solver will then try
to make the employees follow exactly one of the specified patterns. If you do then do not define `startDays` on a pattern, it will default to starting on the first day of each period. If you do choose to define `startDays`, each instance of the pattern
must fall fully within exactly one period. Desired pattern rules with only one defined pattern do not need to define `periods`.
In the following rule, the employees may only work shifts if they are in accordance with either of the two patterns. The periods are defined as each weekend (Friday-Sunday). The first pattern is 3 days long and does not define `startDays` - it therefore starts on each Friday.
Meanwhile, the second pattern is 2 days long and only starts on Saturdays. When the solver follows the second pattern for some weekend, it is therefore allowed to plan whatever it wants on the Friday of that weekend.
```json theme={null}
{
"rules": {
"patternRules": [
{
"id": "spr-strict-weekends",
"importance": "STRICT",
"isDesired": true,
"periods": {
"recurrentDefinition": {
"daysPerPeriod": 3,
"daysBetweenStarts": 7
}
},
"patterns": [
{
"patternDays": [
{
"shifts": { "ids": ["shift-1"] }
},
{
"shifts": { "ids": ["shift-1"] }
},
{
"shifts": { "ids": ["shift-1"] }
}
]
},
{
"startDays": {
"daysOfWeek": ["SAT"]
},
"patternDays": [
{
"shifts": { "ids": ["shift-2"] }
},
{
"shifts": { "ids": ["shift-2"] }
}
]
}
]
}
]
}
}
```
## Patterns with role filters
You can use role filters to make a pattern apply only when an employee works in one of those roles.
The rule below makes it undesirable for employees to work the night shift on both Saturday and Sunday when they are working in role 1 or role 2.
```json theme={null}
{
"id": "spc-weekend-roles",
"importance": "MEDIUM",
"isDesired": false,
"patterns": [
{
"startDays": {
"daysOfWeek": ["SAT"]
},
"patternDays": [
{
"shifts": { "ids": ["night-shift"] }
},
{
"shifts": { "ids": ["night-shift"] }
}
],
"roles": {
"ids": ["role-1", "role-2"]
}
}
]
}
```
## Empty day behaviour
In some cases, it can be desirable to allow a pattern to 'skip over' days if it will be impossible for an employee to follow the pattern on that day. In particular, days where an employee is not available for work or days where no demand is defined can be configured to be skipped over. These two types of empty day behaviour can be configured separately through the `dayOffBehaviour` and `dayWithoutDemandBehaviour` fields on each pattern itself.
The current list of empty day behaviours is as follows:
| Empty day behaviour | Impact |
| ------------------- | ----------------------------------------------------------------------------------------------------------------- |
| **INCLUDE** | Days are always included in the pattern (never skipped over), regardless of whether it is an empty day or not. |
| **EXCLUDE** | Days are always excluded from the pattern (always skipped over), regardless of whether it is an empty day or not. |
| **MATCH** | Days are included in the pattern as long as the pattern can be matched with a day off on that day. |
In order for a day to qualify as a day without demand, there must be no demands defined on that day. In order for a day to qualify as a day off, the employee must be configured to be unavailable for work on that day. This can be done through one of the following rules:
* [**Availability**](/v2/rules/availability): The employee is strictly unavailable for work on the entire day.
* [**Utilization**](/v2/rules/utilization): The employee has a strict maximum of 0 hours or shifts on the day.
* [**Period Distribution**](/v2/rules/period-distribution): The employee may work a maximum of 0 periods, which includes the day.
## Metrics
The following [status metrics](/v2/concepts/metrics) are available for tracking on Pattern rules: