Over the years, Asana has made a number of subtasks-related improvements throughout the app (e.g., in projects, advanced search, reporting/dashboards, and rules), and perhaps more will come. But as of right now, here’s what I think you need to know to be successful–a cheat sheet for subtasks.
Recommended Uses for Subtasks
Break down tasks into component parts and optionally assign and home to other projects
Simplify and declutter the main Tasks List by subordinating work to subtasks where appropriate
Reduce the number of projects by using a task with subtasks instead of a project with tasks; a good example is to use a single project for a recurring staff meeting housing each meeting recurrence as a task with subtasks for action items, agenda, or both
Group related subtasks in Subsections, an additional level of hierarchy (see Subsections below)
Approval-type tasks (Business/Enterprise plans) work best as subtasks (because they narrowly represent solely the act of approval, not the underlying task itself) and thus also enable multiple approvers using approval subtasks for each
The Assign Duplicates feature works best using subtasks for the multiple people assignments allowing the parent task to contain the single-sourced information; see also Assign multiple assignees on one task - #198 by lpb
Complex workflows often require the use of subtasks (with metadata); many organizations of all stripes, including Asana, make wide use of subtasks
Use subtasks wherever appropriate, but see caveats below; Reject advice like “Never use subtasks” or “Never more than n subtasks”
Did You Know?
Add to project (Tab+P), which is unfortunately hidden except for the subtask’s “. . .” menu, allows you to home/multi-home a subtask into one or more project(s) where it appears as a top-level task
An often-used workaround (see Caveats below re features that don’t work with subtasks) is to use this tactic to home a subtask back into the parent task’s project, specifically in a Hidden Subtasks section which is kept collapsed and out of the way as the last section
Subsections (Tab+N while your mouse cursor is anywhere in the Task Detail pane), which are unfortunately completely undiscoverable in the user interface, permit grouping subtasks visually, perhaps by a task’s workflow phases, like Draft, Finalize, and Publish
A rule (Business/Enterprise plans) can mark a parent task complete (or many other actions) once all its subtasks are complete
You can easily navigate subtasks in unsorted List Views (using expand/collapse arrows to the left of the task title)
You can even easily see sub-subtasks titles, completion state, assignee, and due date (scroll down in the right-side Task Detail pane)
A subtask is not automatically a member of the parent task’s project; e.g., a subtask assigned to you will appear in your My Tasks not showing a project name; also, Calendar, Timeline, and Workload only work with top-level tasks (Enterprise plan Universal Workload is ok)
Consider using the Hidden Subtasks workaround above
Since both the subtask and its parent task names appear (as Subtask name < Parent task name), include contextual info in the parent task name to disambiguate otherwise similar subtasks like Draft outline < 2024 Year-End Report
Expand/collapse arrows in List View Main tasks list are unavailable if sorted and for certain filters
Prototype your workflow design against all use cases to make sure you’ve understood these caveats before implementation
Generally limit hierarchy to Top-level task > Subtask > Sub-subtask, and for Sub-subtasks only utilize you can easily see in the Subtask’s Task Detail pane: Title, assignee, due date, and completion state, and thus avoid having to “pogo stick” into and out of subtasks
Consider only using Top-level task > Subtask (eliminate use of Sub-subtasks) if you’re not using List View or if it is sorted/filtered in a way that won’t offer expand/collapse arrows
I hope this subtasks solution summary is helpful. What did I leave out that can enable others be successful with subtasks?
One thing I would perhaps mention is that tasks can be expanded to show 1st-level subtasks in the Board, Timeline and Gantt views, irrelevant to any sorting applied, unlike currently in the List view.
Additionally, using subtasks for Approval type tasks is a great method. However, when used in combination with the rule ‘when all subtasks are complete → complete parent task’ this could be an issue because when an Approval is marked as ‘Changes requested’ or ‘Rejected’ it essentially completes the subtask. In most cases, this may not signify the ‘positive’ completion of the parent task. So as a workaround, when all (approval) subtasks are complete, the action I would instead use would be to ‘add a comment’ that reads: “@Assignee, please check whether all subtasks are approved, and if so, mark task complete”. What do you think?
And yes it’s sad that this feature isn’t more visible because many users could benefit from them to better organize their subtask lists. Might also be on purpose though so people aren’t tempted to create too many subtasks with kind of sections instead of projects with tasks. Not sure but yeah not really visible at all.
When our team moved to using subtasks more regularly, we were disappointed to lose the color-coordination that allowed us to see at a glance (in the Calendar view) which tasks were associated with which projects. But we weren’t loving the multi-homing trick where each subtask was added to the main project.
Here’s a workaround I created:
I built projects for each color (dark pink, teal, etc.). I then adjusted all of my templates and task templates to automatically add subtasks to the appropriate color based on what type of project we were working on (teal for newsletters, dark pink for prayer cards, purple for web, etc.).
Now we have our colorful calendars back, which helps us group tasks and prioritize more quickly (so we don’t have to go into the description for each task to remind ourselves which projects they’re connected to). Might not work for every team, but it’s been great for us!
Richard, thanks for those additional points, which are valuable for sure. I was trying to limit the length of the post (didn’t really succeed!), but these are certainly helpful, and I do agree with your quasi-automation for approval subtasks. It would be nice if Asana provided more granular rule choices for those so we could distinguish Approve vs the other two, which are essentially not approving. I often recommend to clients wanting to automate approvals with rules that they should use their own single-select custom field for the top-level task instead of subtask approvals, but your approach is a good hybrid.
I remain baffled as to why sub-tasks are not automatically part of parent task’s project. This is SOP with any other PM software I’ve used. IMO it is a major flaw of Asana as a PM tool requiring too many “work-a-rounds” which is wasted time. Also, it limits filtering functionality in the list view.
We use the ‘add to project’ feature for subtasks to great effect in Agile ways of working. We have ‘backlog projects’ with user stories as cards, with subtasks within them. We use the ‘add to project’ feature to add the subtask as a (linked) card in itself on the separate Kanban board that we use to manage sprints.
We leverage subtasks quite a bit in our instance. I recently was asked whether there is a way to prioritize subtasks based on their relative priority to our business and not by due date. So, if someone is looking at their My Tasks is there a way to sort that list by priority not date. We’ve created a custom field for priority that shows up on main task cards but unfortunately, it doesn’t carry over into the subtasks. Any ideas on a work around?
One approach: If the Priority custom field is org-wide (not local to a single project), anyone may add that custom field to their My Tasks and then sort on it (using Group by: Priority) or filter on it (in the Filter dialog). You would then need to manually (or perhaps via a third-party automation) set Priority in subtasks (first-level subtasks inherit the custom fields of their parent).
Another approach: Include an emoji or [High], etc. in the title of the parent task, either manually or with a third-party automation. Since subtasks titles appear followed by the parent task title (after a “<” character) each person in their My Tasks can see the relative priority and triage manually.
Thanks @Ipb!
We have note used sub-tasks as much as I would like because we can’t figure out how to filter the “My Tasks” list to include sub-tasks from projects where the parent task is not assigned to the same person. I’m hoping I’m just missing something and would welcome any thoughts from anyone!
Thanks again for continuing to provide great information !
Re your question: I usually just manage this as part of the normal course of how I recommend My Tasks is managed, summarized here:
It’s a one-time effort, for example, to triage a parent task you want to ignore because you will instead work at the subtasks level in your My Tasks–just move it to a collapsed Later section once (though it’s true there’s no easy way to automate).
Or perhaps you can avoid the assignment of a parent task if you’re intending to assign all the subtasks.
I think it would depend on the specific use, but what I’m saying is, it hasn’t posed a significant problem that I’ve seen with clients enough to discourage subtasks use if they’re needed.
From tests I tried, it looks like subtask headers can be removed by deleting/removing all of the text from the header label. Once that is gone and you click outside the header it seems to disappear.
