Sub-tasks & delegation: how work rolls up the tree

A sub-task breaks a task into a smaller piece of work. Delegation is the same thing aimed at someone else: it spawns a sub-task, pre-filled from the parent and assigned to another person, and it makes you (the delegator) that sub-task's manager - so you review what comes back. Because a delegated task is a sub-task, the two behave identically once work finishes.

When you delegate your own task

When the task you delegate from is your own, the Delegate window asks And TASK-…? - what happens to your task while they work:

I hand it over: it waits for this sub-task (the default). Your task goes to Waiting on sub-tasks at once. If you were working on it, your time on it stops. You are free to start your next task, even where only one task may be in progress at a time. Your task closes by itself when the sub-task is done.
I keep working on my own part. Your task stays exactly as it was, still yours to work on. When you press Finish, it waits for the sub-task if that is still open.

Delegating your own task: press Delegate and choose the person; the Delegate window asks what happens to your task. Hand it over and your task waits, your time on it stops and you are free; keep working on your own part and your task stays as it is until you finish it. The sub-task opens as a draft for you to finish and publish; they do it; you review it; when it is done, your waiting task closes by itself with its grade.

Hand it over when nothing is left for you to do. Keep working when part of the job is still yours: handing over cannot be undone, and a waiting task closes as soon as its sub-tasks are done.

A manager delegating from somebody else's task never changes that task: its assignee is still working on it.

Wait for sub-tasks

Wait for sub-tasks on the task page does the same hand-over for a task that already has open sub-tasks: ones you created by hand, or ones you delegated before this choice existed while your task sat in Ready to start. The assignee or the task's manager can use it while the task is Ready to start, In progress or paused at clock-out. It asks first, because there is no way back to working on the task yourself.

How completion rolls up the tree

Flow: how sub-task and delegated-task completion rolls up the task tree

When a sub-task reaches a terminal state - Done (rated, or auto-approved after the 48-hour review window) or Cancelled - the engine tries to release its parent:

A parent waits only once its own part is handed over: when its owner presses Finish while it still has open dependent sub-tasks, delegates and hands it over, or presses Wait for sub-tasks. It then shows Waiting on sub-tasks instead of going to review. (If its sub-tasks are marked independent, Finish goes straight to In Review and they never roll up.)
A parent is released only when every sub-task is terminal. Until then, finishing one just waits for the others.
If at least one sub-task is Done, the parent auto-completes - with a grade that is the roll-up (average) of its children's grades. That completion is itself terminal, so it repeats one level up: the result propagates up the whole tree.
If every sub-task was Cancelled, the parent goes to In Review instead, so a person decides - nothing was actually delivered.

Who can create sub-tasks & delegate

The same authorization applies to a plain sub-task and a delegated one. It has two parts: the permission you hold and your relationship to the parent task.

Permission matrix: who can create sub-tasks and delegate, and the permission each action needs

What each permission unlocks

No permission (self-service): on a task assigned to you, you can start it, finish it, record its output, and claim a pooled one - but you cannot create sub-tasks or delegate.
TaskCreate: create sub-tasks and delegate - but only on a task you are the assignee or manager of, and only to yourself, your own manager, or the people in the departments you manage (you cannot delegate to yourself). A team can be any department: one you don't lead gets it as a request, and its manager assigns it (see Send a task to a department).
TaskAssignAny (together with TaskCreate): widens the delegate/assign target to anyone in the organisation.
TaskManage: all of the above on any task (it bypasses the assignee-or-manager rule), plus reviewing, rating and reopening. Implies Create and AssignAny.
Administrator: unrestricted.

On a project milestone, its leader can also give the milestone's tasks to the people of the department that delivers it, without TaskAssignAny. See Leading a milestone.

The relationship rule

Sub-tasking and delegating both make you the new sub-task's reviewer, so both follow current responsibility - not who filed the task. Only the parent's assignee or manager may do them. The creator alone has no standing: by default the creator is the manager (so they usually qualify that way), but a creator who handed the manager role to someone else can no longer restructure the task.

Plain sub-task vs delegated sub-task

A delegated sub-task always has an assignee (someone else); a plain sub-task can default to you.
A delegated sub-task's manager is you, the delegator - so you review and rate the returned work; a plain sub-task's manager is whoever created it.
A delegated sub-task is pre-filled from the parent (description, priority, target, link), and its returned output bubbles into the parent's chat, with a one-click "Use as my result."
Only delegating asks And TASK-…?. A plain sub-task never changes the parent; use Wait for sub-tasks if your own part is done.
The roll-up on completion is identical for both.

Always-on limits: the parent must be open (not Done or Cancelled), and sub-task nesting is capped at 5 levels deep.