To Subtask or not to Subtask

I made a comment on another thread that I’m not a big fan of subtasks, and @Alexis asked me to elaborate—so here we go! It’s not that subtasks don’t have value, I just think they are easily overused by people (especially when they are new to Asana). They actually have a number of limitations, so I try to use sections and tasks instead of tasks and subtasks.

Here’s a list of some of the biggest negatives in my opinion:

  1. It is MUCH harder to access information at a glance when using subtasks. You can look at a project contains only a few tasks in it that appears nearly complete, but there could be a LOT of work if each of those tasks as a dozen subtasks. You have to click on every task one at a time to try to get a better understanding of the scope of work. This can make it really difficult for project managers since there is no other visualization built into Asana like Gantt charts.

  2. Subtasks don’t automatically inherit the assignee, due dates, tags, or some other information of the parent task. This is VERY confusing for people just learning Asana, and I know this from training dozens of organizations when they are deploying Asana. They think the parent task is assigned to Bill, so the subtasks must be, too. Or that they obviously need to be done before the due date of the parent task so they don’t add due dates. This leads to major #fails

  3. Subtasks don’t appear in a project calendar view. Again, if you rely on subtasks as a major part of your workflows, then your project calendars are pretty much worthless because they’re missing half of the information.

  4. You can’t create subtasks via email. This adds additional time to classify tasks.

  5. Subtasks can’t contain custom fields. Now you’re limited about what you can do with them once you’ve committed to an organizational structure reliant on subtasks.

  6. Subtasks aren’t exported in JSON. This probably doesn’t affect many people, but still another shortcoming. (I think this is still accurate?)

  7. Recurring tasks can’t create recurring subtasks with proper dates. This was covered in this thread, but the gist is that basically if you’re using subtasks in a recurring task you can’t have your subtasks update to new dates in the future when the recurring parent task is created. For a lot of use cases, this makes them ineffective as part of recurring tasks.

Now I’m glad there are subtasks because there are cases where they are very helpful. My favorite two scenarios are as Task Templates for small workflows and when using Tasks as a representation for something else (like a person’s name as part of a CRM project). But 90% of the time, I think Sections + Tasks works better.

Any thoughts? Any reasons I missed?



I do like using subtasks to hold certain documents stored in Asana for instance Financial Statements or periodic reports that you want to have previous versions.

Financial Statements
01/31/17 Subtask
02/28/17 Subtask…

I use Sendana to email the statements from accounting software some big, some like Quickbooks and then drag them into a Task in descending chronological order.

I’m a big fan of projects, sections, and custom fields! Sections and custom fields is allow you a lot of search and sort flexibility And they’re helpful for keeping track of work in one view, rather than jumping between tasks, subtasks, and sub-subtasks.

That said, I do think subtasks can be super useful when I want to keep my work consolidated and when I want to collaborate on mini tasks with different people. If I need to monitor the subtasks in my calendar or in a project view, I just Tab+P to add the subtask to a project.

I really liked using a task with subtasks when I was planning a community launch event this week, actually. I created a community launch event checklist task with lots of subtasks. I commented to the people responsible for the subtasks within the those subtasks, rather than in the parent event task. It kept the parent task very clean and prevented a deluge of notifications for people who weren’t necessary relevant.

My takeaway - start with custom fields and sections if you can. But don’t underestimate the power of subtasks when you’re collaborating. :slight_smile:


I definitely echo @Todd_Cavanaugh’s general thoughts around ideally tracking work with parent tasks and categorizing that work with sections and custom fields (vs. layers and layers of subtasks, which tend to get buried).

As an Asana Success Manager, my general rule of thumb is to only go one layer deep with subtasks and have conversations as comments on the parent task. This ensures that you can see the full story just by clicking into a task and not wonder what’s buried several layers deep.

Another pro tip if you do use subtasks — Make sure they’re all assigned. :slight_smile: That way they’ll show up in the assignee’s My Tasks and not get lost in the mix.


I also agree with Todd’s point number 1 about subtasks. I strongly encourage others not to use subtasks and to stick with sections and tasks only.

This is because I have seen their usage cause more problems and confusion then benefit. I have seen information in subtasks get buried or lost.

I would point to the following as the main reasons.

  • Can’t see if or what subtasks their are from the a project’s list view.
  • Can complete a task with incomplete subtasks.

Losing tasks is counter to one of the primary values of Asana. But their is value in another layer of hierarchy that a subtask could provide.

I propose the following changes as minimum requirements to make subtasks valuable.

  • Make subtasks visible from a projects task list. Display them differently so it is clear that is it a subtask to a task. (i.e. subtasks listed below a task, subtasks indented from the task in the list, tasks and their subtasks will only move in the list order as a single unit)
  • Don’t allow a task with incomplete subtasks to be completed, while providing a meaningful error message.

One other due date rule that I had on my previous software was that the due date of the master task was not entered. It was calculated to be the latest due date of any sub-task. It kind of made sense that a parent task cannot be technically due before a sub-task contained in it. But I also recall the software had a Begin Date/End date so maybe that combination made it even more logical the way it was handled.


My team had a similar problem with subtasks. At a glance, it is unclear whether a task has subtasks, and because of this uncertainty, some people wary of using subtasks. Unfortunately, our projects require multiple layers of hierarchy, so we were using section > task > subtasks frequently.

I recommended that subtasks only be used for tracking granular detail of a particular task rather than as a method of grouping hierarchy.

Side-note: What would be nice is Sub-sections. Anyone else?


A simple 4/7 (completed/total tasks) indicator or something on the task itself so you can easily see it’s status without drilling down into it.


I second this! Something like this would be incredibly helpful.


Subtasks can be powerful and limiting at the same time. To ensure a successful deployment, I believe it is critical that the use of subtasks is standardized as much as possible within the organization.

Also, to have a clear view of a project, including subtasks, create a saved search that includes tasks and subtasks. To Asana’s credit, saved searches have a calendar view…


Subtasks are very important for our team and as @Todd_Cavanaugh has outlined these are our list of grievances too.

I would add it is extremely difficult to assign dependencies. Hidden in a dropdown list, no logic in the search function. The default should be the task directly above. A simple drag and drop connector.


It’s definitely easy to get carried away with nested subtasks, but my team finds them essential for precisely the reasons @Todd_Cavanaugh doesn’t like them in #2 and #3 in his original post.

Our primary use of Asana is for an editorial calendar. We do this the way Asana recommends, which is to make the entire calendar one project, each content item a task, and each steps to create the content a subtask. The sections are used to organize content; in our case we use months, but some teams use publication stages (e.g. draft, final review).

The key benefit of using tasks and subtasks in one huge project is that all the tasks (which represent content items) appear on the calendar, and the subtasks do not. Asana is very inconsistent about whether subtasks appear on calendar views, and it should just be an option. But in this case it’s very useful that they don’t appear, because this way we can see that we’re making Announcement X (a task) on Wednesday and Announcement Y (another task) on Thursday, without the clutter of “proofread 17th draft” (a subtask).

The assignee for the task (the content item) is the person responsible for overseeing the production of that item, but the subtasks (the steps to create the content) could be assigned to several different people. Thus, we actually appreciate that subtasks don’t inherit assignees and due dates from parent tasks.

We’ve had over 150 content items for Q1 2017, about half completed so far and half on the radar. If we used separate projects for each content item, that means we’d have about 75 items in the project list for just content alone. The content items also wouldn’t appear on one calendar unless we used tags and a saved search, but then all the subtasks would also appear (see above re: inconsistent display of subtasks on calendar views). If we used one project for the content calendar but sections instead of tasks for the content items, the list would be impractically long because each section would have about 15 items. We also couldn’t have discussion about one content item – discussion would have to be about a step in the workflow.

It would be nice if the > symbol on the right edge of a task were more prominent. This indicator that there’s something “behind” the task (subtasks, description, conversation) is very subtle and easy to miss.

I’d also like to be able to reorder subtasks in the mobile app. You can only reorder tasks right now.


@briankb @Colin_Flanders You can create Sub-sections. Just use the colon at the end of the task create as sub section, see screen shot below.


1 Like

Thanks @Alexis for directing me to this Topic.


Is a pain for me in setup how I make sure I submit my Expense Reimbursement Invoice on time.

I am a great fan of Sub Tasks, yes understand the limitations that @Todd_Cavanaugh and others have highlighted, but I could not do with out them.

I use Sub Tasks for

  • The next Step in the chain of completing the Task. eg. Get Document Reviewed, Organise Followup Meeting.
  • Storing information, emails, attachments etc.

I don’t always assign an owner to the Sub Task or set a due date to the sub tasks, as it is often dependant on the completion of another Sub Task. Now being a non premium user I don’t get the full functionality of Mark Tasks Waiting on and Custom Fields.



Hi, @Jason_Woods, thanks for the input. Yes, we use Sections all the time and love the functionality. It’s a great way of organizing our projects. I guess what I meant by a sub-Section is a Section within a Section, or layers of hierarchy for Sections (as opposed to Tasks and sub-Tasks). Perhaps this isn’t feasible or may not be what others are looking for. Just a thought.


Okay understand, yes can see how Sub Sections could be useful.

1 Like

RE: #3 and #5, if your subtask is added to a project manually, the custom fields associated with that project will appear in the sub-task. Also, if a sub-task is added to a project AND has a due date set, it will also appear in that project’s calendar view.

Todd is absolutely right about those two items by default, but I just wanted to comment that those two things are possible by adding a sub-task to a project manually from the drop down menu.


Thanks, this is good to know. I think the name of the command is confusing, though, since the subtask seems like it’s already in the project.


Thanks for clarifying that, @Jeff_Maughan. In my opinion, it’s still supporting my overall point, however, that subtasks can be confusing for new people or people who aren’t productivity nerds like probably everyone on this forum. “A subtask within a project is not part of a project unless you specifically add it to a project.” That is really, really complicated for a whole organization to understand and follow correctly.


Yeah… I agree with you that it is confusing @Todd_Cavanaugh and @Craig_Fifer… I just noticed that those two things were possible and wanted to point it out in case it made a difference for anyone who happened across this thread.

On the other hand, I can appreciate that it works the way it does because it gives us as end users flexibility, although it would definitely be better - especially for large organizations as you mentioned - to also have a checkbox or something in the project settings to determine globally within a project whether or not sub-tasks for that project were included explicitly in the project rather than indirectly through their parents.

At any rate, thank you for starting this thread @Todd_Cavanaugh… it has been very educational. :slight_smile: