Dart’s automations are designed to reduce manual clicks and keep your project board consistent. By enabling these triggers, you ensure that the relationship between your parent tasks and subtasks remains coherent without constant maintenance.
You can manage these rules by navigating to Settings > AI > Automations.
Automations
1. Parents complete when all subtasks complete
This logic flows from the bottom up. When the final open subtask within a parent task is marked as "Done," the parent task automatically marks itself as complete.
Why use this: This is ideal for tasks that are simply containers for a checklist. If a "Blog Post" task has subtasks for "Draft," "Edit," and "Publish," finishing the "Publish" step naturally means the whole job is done.
When to turn it off: Disable this if the parent task requires a final review or a specific "shipping" action that is distinct from the subtasks. For example, you might finish all code subtasks, but the parent feature request shouldn't close until a manager verifies it in production
2. Parents start when any subtask starts
This provides a bottom-up status update. As soon as you move a subtask from "Todo" to "Doing" (or any active status), the parent task transitions to "Doing" as well.
Why use this: It provides an accurate signal of activity. It prevents the common scenario where a team is actively working on components of a project, but the project itself looks stagnant on the high-level roadmap because no one updated the parent task
When to turn it off: You might disable this if the main task has separate work from the subtasks that needs to be started separately from them
3. Subtasks change dartboards with parent
This ensures context preservation. When you move a parent task to a different dartboard (e.g., from "Backlog" to "Current Sprint"), all associated subtasks in that board move with it.
Why use this: This is essential for workflows where you move entire units of work between stages. It ensures that you don't leave straggling subtasks behind in the backlog when the main feature moves into development
When to turn it off: Disable this if your subtasks live on different functional boards than the parent. For instance, if the parent task lives on the "Product Roadmap" board, but the subtasks live on a specific "Engineering" board, you likely don't want the subtasks moving just because the roadmap status changed
4. Subtasks complete with parent
This logic flows from the top down. When you mark a parent task as complete (or canceled), Dart effectively "cleans up" by marking all remaining open subtasks as complete.
Why use this: This works best as a cleanup mechanism. If you decide to cancel a project or close a ticket because it is no longer relevant, this automation ensures you don't have "orphan" subtasks cluttering your active views
When to turn it off: Turn this off if you frequently close parent tasks but need to roll over unfinished subtasks to a new parent or a new sprint, or if you prefer to manually mark subtasks as complete in order to double check that work was truly finished
5. New subtasks replicate parent
This acts as an inheritance or templating feature. When you create a new subtask, it will automatically adopt most properties from the parent, such as assignee, tags, and priority.
Why use this: This can be a time-saver for data entry. If a parent task is tagged "Marketing" and "Q4 Priority," any subtask you create inside it will essentially know it belongs to those categories without you having to manually tag it
When to turn it off: Disable this if your parent tasks and subtasks are commonly assigned to different people or have different levels of priority, etc.
6. Blocked task dates update with blocker
This manages your blockers (dependencies) and timeline automatically. If Task B is blocked by Task A, and Task A’s due date is pushed back to after Task B's due date, then Task B's due date will also update to the same due date.
Why use this: This keeps your roadmap realistic. If a prerequisite is delayed, this automation immediately shows you the ripple effect on downstream tasks, preventing impossible deadlines from remaining on the calendar
When to turn it off: You might want this off if you have strict, immovable deadlines for the final task regardless of upstream delays. In that case, you want to see the timeline compression rather than having the system automatically extend the final due date