Tasks

Manager view and acting on behalf

Managers see their reports' open tasks with workload per person, act on a task on the assignee's behalf with a note, and reassign work.

Reporting lines

Each workspace member can have a manager in that workspace. Set it on the Team page (Reporting lines: pick a manager per member; needs Manage roles), with PUT /api/v1/users/{id}/manager, MCP users_manager_set or usertasks users set-manager <id> --set manager_user_id=<manager-id> (--set manager_user_id:=null clears it); usertasks users reports me lists your reports. A member cannot manage themselves and loops are refused.

Directory sync fills reporting lines from the directory's manager attribute:

A line the directory sets is marked From directory sync and replaced on the next sync; a manager the directory names but who is not synced into the workspace leaves the line as it is.

Anyone with at least one direct report is a manager. Indirect reports are their reports' reports, up to 10 levels.

My team

Tasks → My team appears for managers only. It lists the open tasks of your direct reports (tick Include indirect reports for every level) with:

• workload per person — open, overdue and SLA-breached counts (click a person to filter);
• filters for person, status, priority, workflow, Overdue and SLA breached (the waiting run's SLA is breached or the task's escalation fired);
• grouping by person, overdue due dates highlighted;
• Act on behalf and Reassign on each task.

On a phone the list is read-only.

The same view is GET /api/v1/tasks?scope=reports (indirect, assignee_id, status, priority, workflow_id, overdue, sla_breached), MCP tasks_list with scope: "reports" and usertasks tasks team. It returns reports (workload per person) and tasks, and needs a user (a user-bound key or OAuth token) and View own tasks.

Acting on behalf

Open a report's task. A banner says you are acting on behalf of the assignee and asks for a reason; the outcome buttons, form buttons and Save then act for them. What happens:

• the response counts as the assignee's (completion rules are unchanged);
• the task records actioned_by = you and actioned_on_behalf_of = the assignee;
• the history shows on behalf of … on the event, the lifecycle event carries on_behalf_of, on_behalf_note and acted_as (on_behalf or break_glass) — so do the event stream (task.task_response) and log export;
• an audit row (act_on_behalf / break_glass on the task) is written;
• the assignee gets a notification and an email with your reason;
• the resumed workflow sees {{actioned_by}}, {{actioned_on_behalf_of}}, {{actioned_on_behalf_of_name}} and {{on_behalf_note}}, and {{task.actioned_on_behalf_of}} is set on the task.

By API: POST /api/v1/tasks/{id}/action with "on_behalf": true and "on_behalf_note" (MCP tasks_complete_workflow / tasks_respond with on_behalf, CLI usertasks tasks complete <id> --on-behalf --note "…"). Without on_behalf a manager gets 403, as does anyone outside the assignee's manager chain.

Reassigning a report's task

Reassign moves a report's open task to another of your reports or to yourself (Take it myself), with an optional comment; both people are notified. It needs Assign tasks, and a workflow task only moves when its step allows redirects.

Permissions