Edit-group
A Group holds a set of tasks within one Scenario. The scenario must exist first, since a group belongs to exactly one.
Contents
Creating a group
- Open Author → Tasks.
- Click Add group in the task hierarchy header.
- Select the Scenario the group belongs to.
- Fill in the remaining fields and click Save.
Fields
| Field | Notes |
|---|---|
| ID | Assigned automatically; read-only. |
| Name | Mandatory and unique. |
| Enabled | When cleared, none of the group's tasks are planned. Takes effect at planning time; it does not remove tasks from a processing already running. |
| Scenario | The owning scenario. Type to search and pick from the list. |
| Description | Free text. |
| Multiday mode | The default for tasks in this group set to Group setting. See Parallelism. |
| Parallel limit | 0–999. Maximum tasks from this group running in parallel. |
| Load limit | 1–999999. Maximum sum of task weights running in parallel within the group. |
Starting and finishing task
These two fields are shorthand for a set of dependencies that would otherwise have to be created by hand.
- 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 are the natural way to express "prepare, then do the work" and "do the work, then close off". Using them is preferable to creating the equivalent dependencies individually, because the relationship stays correct when tasks are later added to or removed from the group.
Group dependencies
The Dependencies list defines dependencies at group level. Add a group by typing into the Add... box; remove one with the button beside the entry. Clicking an entry opens that group.
A group dependency behaves as a dependency between every combination of tasks in the two groups. Two consequences are worth remembering:
- a single unfinished task in the group depended on blocks everything downstream
- priority is not inherited through group dependencies, only through task dependencies
For this reason task-level dependencies are the preferred form; keep group dependencies for genuinely coarse boundaries. See Dependencies and Prioritization.
Notifications
The Notifications list receives notifications when any task in the group fails. This is in addition to any notification assigned to the individual task.
Assigning at group level is usually the right default: it covers new tasks automatically as they are added to the group.
Changes to the dependency and notification lists apply immediately and are not part of Save.
Practical notes
- Use groups to make the task list navigable. In a project with hundreds or thousands of tasks, the group is what makes the tree usable.
- Disabling a group is the clean way to take a whole area out of service without touching individual task definitions.
- Groups cannot be nested.
- A group can only be deleted once it contains no tasks.
