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.
Automations overview
You can manage these rules by navigating to Settings > AI > Automations.
Functions
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 during the planning phase if you are organizing subtasks but aren't ready to officially declare the main initiative as "started" to stakeholders
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 Scrum or Kanban 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
5. New subtasks replicate parent
This acts as an inheritance or templating feature. When you create a new subtask, it will automatically adopt properties from the parent, such as tags, priority levels, or specific custom fields.
Why use this: This is a massive 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 Marketing and Q4 without you having to manually tag it
When to turn it off: Disable this if your parent tasks are general containers (e.g., assigned to a Project Manager) but your subtasks are always specific delegables (assigned to different specialists). You may not want the subtask to inherit the PM's assignment or generic tags
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 by three days, Task B’s due date will also shift back by three days.
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 (the "crunch") rather than having the system automatically extend the final due date