Group
A group is a set of tasks that are similar from a planning point of view, or that belong together in the logical architecture. Its first purpose is to keep the task list manageable in projects containing hundreds or thousands of tasks. Its second is to act as a container for controlling execution — through group-level dependencies and group-level limits.
Each group belongs to exactly one Scenario. Groups cannot be nested inside other groups.
Contents
Attributes
| Attribute | Description |
|---|---|
| Name | Name of the group. |
| Description | Free text. |
| Enabled | Whether the group's tasks are planned. Disabling a group excludes all of its tasks from planning without changing the tasks themselves. |
| Scenario | The scenario the group belongs to. |
| Parallel limit | The maximum number of tasks from this group running simultaneously. |
| Load limit | The maximum combined weight of tasks from this group running simultaneously. |
| Multiday mode | The default multiday mode for tasks in the group that are set to Group setting. |
| Dependencies | Group-level dependencies. See below. |
| Operators | Operators notified when a task in this group fails, in addition to any assigned to the task itself. |
| Starting task / Finishing task | Dependency shorthands for the entry and exit points of the group. See below. |
Starting and finishing task
These two settings stand in for a set of dependencies that would otherwise have to be created individually:
- Starting task — the selected task must finish successfully before any other task in the group may start. Equivalent to a dependency from that task to every other task in the group.
- Finishing task — every other task in the group must finish successfully before the selected task may start. Equivalent to a dependency from every other task in the group to that one.
They express the common "prepare, then work" and "work, then close off" patterns. Prefer them to the equivalent hand-made dependencies: the relationship stays correct when tasks are later added to or removed from the group.
Where both a group limit and a connection limit apply to a task, the stricter one is enforced. A task can therefore be held back by a fully occupied connection even though its group has capacity. See Resource management.
Group dependencies
A dependency can be defined between groups rather than between individual tasks. A group dependency is effectively a dependency between every combination of tasks in the two groups: no task in the dependent group starts until every task in the group it depends on has finished.
This is a convenience for cases where the boundary between two groups is clean — for example maintenance tasks that must run only after the main processing is complete.
Two consequences are worth knowing:
- One unfinished task blocks everything downstream of the group. When a processing appears stalled behind a group dependency, the cause is usually a single member that has not completed. See Investigating a stalled processing.
- Priority is not inherited through group dependencies. Tasks in a group do not take on the priority of tasks in a dependent group. Only task-level dependencies propagate priority. See Prioritization.
For this reason a dependency between individual tasks is the preferred form, and group dependencies are best kept for genuinely coarse boundaries.
Disabling a group
Disabling a group is the practical way to take a whole area of processing out of service — for example while a source system is unavailable — without touching the individual task definitions.
It takes effect at planning time. A group disabled while a processing is already running does not remove its tasks from that processing; to stop tasks in a run that has already been planned, hold them or pause the processing instead. See Controlling a processing.
