Skip to main content

Tasks

Demands can have an associated Task, which can be used to specify the type of work that should be done during a demand. Demands with a task can only be covered by shifts on which this task is listed as a possible task.

For regular shifts, a single required task can be specified on a Shift Interval. Generated shifts can cover any task by default, but a limited set of possible tasks can be specified. Please refer to the schemas in Shifts and Shift Generation for more details.


Attribute requirements

Some tasks might require specific experience or skills, which can be specified in attribute requirements. The corresponding shifts or demands can only be assigned to employees that meet all requirements.

Payload example

In the example below, task-A can only be assigned to employees with the drivers-license and english-language competences. task-B can only be assigned to employees from the finance or hr departments, and at least one of these departments is required.

{
"tasks": [
{
"id": "task-A",
"attributeRequirements": [
{
"key": "competence",
"values": ["drivers-license", "english-language"]
}
]
},
{
"id": "task-B",
"attributeRequirements": [
{
"key": "department",
"values": ["finance", "hr"],
"matchType": "ANY"
}
]
}
]
}

Min / max task duration and cooldown periods

There might be limitations on how long an employee is allowed to work on a task consecutively. This might include work on several different demands with the same task. Minimum task durations could be useful to prevent inefficiently short task allocations, while maximum task durations are often required by law or contractual agreements.

A maximum task duration must be complemented by a cooldown period, which represents the time required before an employee is allowed to work on this task again. Defining a cooldown period without a maximum task duration is allowed and could for instance be used to spread the work on non-popular tasks over multiple employees.

Payload example

After working on task Heavy1 for at most 2 hours, the assigned employee is not allowed to work on this task for the next hour. Task Repetitive2 cannot be assigned to an employee for less than 30 minutes. For Task OncePerDay, a cooldown period is defined without a maximum task duration.

{
"tasks": [
{
"id": "Heavy1",
"maxMinutes": 120,
"cooldownMinutes": 60
},
{
"id": "Repetitive2",
"minMinutes": 30
},
{
"id": "OncePerDay",
"cooldownMinutes": 1440
}
]
}

Task groups

In case there are multiple similar tasks with a common minimum or maximum duration, they can be grouped into TaskGroups. The min / max / cooldown properties defined on a task group will hold for all tasks in this group. In particular, the cooldown period represents the time required before an employee is allowed to work on any task from this task group again.

A task can belong to multiple task groups. It will take on the most strict min / max properties from all task groups it belongs to. If min / max durations are defined on both a task and a task group, the task properties will take precedence. If there are multiple cooldown periods applicable between two tasks, the longest one will be used.

Payload example

In the example below, heavy and repetitive tasks are grouped.

Task HeavyAndRepetitive belongs to both task groups. It has a minimum duration of 30 minutes, a maximum duration of 60 minutes. After working on this task, a cooldown period of 90 minutes is required before working on a Heavy task again, and 45 minutes before working on a Repetitive task again. In particular, working on a HeavyAndRepetitive task again can be done after the longest applicable cooldown period, which is 90 minutes.

Task VeryHeavy requires a lower maximum duration than the common value on the Heavy task group, so the maximum is overruled on Task level. Similarly, 30 minutes is too short to get in the flow for Task RepetitiveWithSetup, so the minimum is overruled on Task level.

{
"tasks": [
{
"id": "VeryHeavy",
"maxMinutes": 45
},
{
"id": "RepetitiveWithSetup",
"minMinutes": 60
},
{
"id": "HeavyAndRepetitive"
}
],
"taskGroups": [
{
"id": "Heavy",
"maxMinutes": 60,
"cooldownMinutes": 90,
"taskIds": ["VeryHeavy", "HeavyAndRepetitive"]
},
{
"id": "Repetitive",
"minMinutes": 30,
"maxMinutes": 120,
"cooldownMinutes": 45,
"taskIds": ["HeavyAndRepetitive", "RepetitiveWithSetup"]
}
]
}

Cooldowns between different Tasks and TaskGroups

In addition to cooldown periods required before working on the same task (group) again, it is possible to specify cooldowns between different tasks or task groups.

Payload example

After working on task A, the following cooldowns are required (provided that task A and B do not belong to task group C): 90 minutes before working on the same task A again, 30 minutes before working on task B, and 60 minutes before working on any task from task group C.

To illustrate that the longest applicable cooldown period between two tasks is used, now suppose that task A and B do belong to task group C. The required cooldown period after task A would be 90 minutes before working on task A again, while it would be 60 minutes before working on task B.

A similar example could be constructed for cooldowns defined on TaskGroup level.

{
"tasks": [
{
"id": "A",
"cooldownMinutes": 90,
"cooldowns": [
{
"taskId": "B",
"minutes": 30
},
{
"taskGroupId": "C",
"minutes": 60
}
]
}
]
}

Assignments

Similar to tasks, Assignments may be used to limit which shifts are able to cover the demand. Only shifts with this particular Assignment are able to cover the demand. This is similar to a task that has no competence requirements. Where you might want to use a Task to specify what should be done during the interval, you might want to use Assignments to further constrain which shifts might cover the demand, e.g. if there is a particular project where only a subset of the shifts might be used. This wouldn't be possible only through tasks as there can only be one task per demand interval.

note

Note that for shift templates, if no Assignments are specified, the generated shifts can cover any Assignment. To limit which assignment may be covered by a generated shift, specify it in assignmentId.