Automation trigger "Subtask created" + actions that target the parent task
Sergio Sapuppo
Problem
Automations only ever act on the task that fired the trigger. When a subtask is created, there is no trigger that fires in the context of the parent, and no action scope that lets me modify the parent. Any parent-level state that depends on the existence of subtasks has to be maintained manually.
Request
New triggers, evaluated on the parent: Subtask created and Last subtask removed.
New action scope: apply the action to the parent task — change task type, change status, add/remove assignee, set a custom field value, add a tag, post a comment.
Use case
In our workspace parent tasks are containers, not units of work: only subtasks are assigned and only subtasks are billable. As soon as someone breaks a task down into subtasks, the parent should automatically have its Task Type set to "Parent Task" and its assignee cleared. When the last subtask is removed, the parent goes back to being a regular assignable task.
Today each PM has to remember these steps manually. A missed one corrupts workload reporting and billing exports, because an assigned parent gets counted alongside its own subtasks.
Why the current options don't cover this
Task created fires on the subtask itself, and every downstream action applies to that subtask only. A generic "subtask removed" event would not help either — the parent must only revert when no subtasks are left, which is why the second trigger is scoped to the last one. The only workaround today is an external service polling the API for parent/child changes, which is not viable as a workspace-wide convention.
Impact
Unlocks a class of parent/child governance rules that are currently impossible natively: ownership normalisation, task-type normalisation, roll-up field maintenance.
Log In
Gabriele Vitale
+1!
This is the single biggest automation gap for anyone running project-based delivery.
We manage ERP implementations where every project (parent task) gets broken into billable work packages (subtasks). The moment a parent is decomposed, three things need to happen automatically:
Parent Task Type → "Container"
Parent assignee → cleared
A custom field "Has Subtasks" → Yes
None of this is possible today. The result: every PM on the team has to remember a manual checklist every time they break down a task and when they forget (they will), we get ghost assignments inflating workload views and billable hours leaking into reports because a parent task is being counted as work alongside its own children.
The "Last subtask removed" trigger is equally critical. We regularly consolidate subtasks back into a single task when scope shrinks. Without a trigger that fires on the parent when it goes back to zero children, we'd need a second manual checklist to undo everything or leave stale "Container" labels on tasks that are now regular work items.
To the point about external API polling: we evaluated it. For a single workspace with dozens of active projects, the polling frequency needed to catch changes in near-real-time makes it impractical and it introduces a maintenance burden that defeats the purpose of having a native automation engine.
This isn't a niche request. Any team that distinguishes between "work containers" and "units of work" which is basically any team doing project delivery, sprint planning, or hierarchical billing hits this wall immediately.