What it does
A simple rule: when a task in a list changes status or gets assigned, IterDone runs one action automatically — notify the assignees or spin off a subtask, no rule-builder or branching logic involved.
Who needs it
Teams doing the same manual step after every status change or reassignment — nudging someone, or always adding a standard follow-up task.
Why use it
Each automation reads as one sentence: when this happens, do that. There's nothing to debug or maintain beyond pausing it if it stops being useful.
How it works
An automation watches one list for a trigger and, when it fires, runs one action — no branching logic, no multi-step chains. Create one from Admin > Automations: give it a name, the ID of the list to watch, a trigger, and an action.
Two triggers are live:
- Status changes — fires when any task in the list moves to a different status.
- Task assigned — fires when a task in the list gets a new assignee.
A third option, Due date approaching, is selectable in the form but isn't wired up yet — nothing currently checks due dates against it, so an automation built on it will never fire. Treat it as reserved for a later release.
Four actions are available once a trigger fires:
- Send notification — notifies the task's current assignees. This works as soon as you create the automation, using the automation's name as the notification title.
- Create subtask — adds a subtask (named "Subtask") to the task that triggered the rule. Also works immediately.
- Change status and Assign to user — meant to move the task to a specific status or hand it to a specific person. The New Automation form doesn't yet include a picker for which status or which person, so an automation created with one of these actions saves but has nothing to target — it runs and does nothing. Pick Send notification or Create subtask for a rule that takes effect right away.
Once created, an automation sits on the Automations list with an ACTIVE/PAUSED badge — Pause and Enable toggle it without deleting it, and Delete removes it outright. A background process checks for fired triggers roughly every 5 seconds and works through anything queued, so there's a short delay between the trigger and the action.