Marquis vs Bastien - Subtasks in Asana: should you limit the number per tasks?


:rocket: @Marquis_Murray and I have a combined experience of 20 years with using Asana and hundreds of clients helped. But we might not agree on everything and we thought it would be interesting for others to see how we align or not on important topics.

And subtasks are such a hot topic. Pick two random consultants and they will probably have a different opinion on anything related to subtasks. One question I get over and over again: how many subtasks is too much subtasks? Should you limit the number of subtasks per tasks? Marquis and I are sharing our visions.

:studio_microphone: Marquis “I recommend a limit”

I recommend limiting the number of levels of subtasks to one or two. Creating too many levels of subtasks can unnecessarily complicate your project and make it time-consuming for team members to navigate. In the list or board view, embedded subtasks can be seen while subtasks beyond that are hidden. My team keeps it simple by limiting subtasks to one or two levels.

Adding too many levels of subtasks can also make it difficult to track the progress of the main task. Asana has recently updated how subtasks are used and visualized within timelines and workload, so my recommendation may change in the future. However, at this time, I suggest limiting subtasks to one or two levels for simplicity’s sake.

:studio_microphone: Bastien “No rule of thumb, but don’t be afraid to turn your task into a project”

For a long time, I thought we could define some kind of a universal limit. Something along the lines of “above 15 subtasks is too many”. I even embedded this limit into a reporting tool we created. The reality is obviously more complicated that this. After talking with many clients and other consultants, Larry Berger being the main one, I realized I couldn’t be so bold.

That being said, the topic of subtasks is a complicated one, but I am sure of something: you are usually better off working in a project above a “certain” number of subtasks. For a lot of reason: it is more confortable and gives you access to more features. But working in a project means that you either lose the ability to “organize” this project amongst other tasks, or you still need to have a task, even though its subtasks went elsewhere. In this scenario, the action “Convert task to project” is a perfect candidate: you get your project to work from but the initial task is still there, it even has a special design, making everything extra clear.

So no, you shouldn’t limit the number, but we need to make sure people are not afraid of creating a project when they have to!

:mag_right: Conclusion: what do YOU think?


Great topic!

You brought up two different topics:

  1. Limiting the number of the subtasks levels.
  2. Limiting the number of the subtasks in one level.

I agree that the numbers of the levels should be limited. I observe my customers struggle with subtasks in My tasks view. They do not know which project these subtasks belong to and they do not know how to check it. Especially if they have plenty projects from one template and one person is responsible for one task (with subtasks) in each of these projects. The same names, the same work, but different projects.

In terms of limited number of subtask in one level I think that it’s not necesarilly. I observe opposite approach where my clients tend to create project with very short list of tasks (one or two) instead of creating the task. In addition the subtasks can serve as the checklist for work in the task so limiting the number could be challenging in that case.


Thanks for the thoughtful remarks, @Bastien_Siebman and @Marquis_Murray!

For more on this topic, its nuances, and why it’s hard to give rules of thumb when so much is case-specific, see also:

That tip mentions this deeper dive, which includes a lot about subtasks with examples and context:

Bonus subtasks-related tip: So many people are still blown away to learn of this completely hidden Asana feature:

As Bastien noted, I’m often a subtasks proponent, but it really depends. During my Asana AMA for Nonprofits earlier this week, I offered a participant an alternative to eliminate subtasks in favor of a custom field; it’s an art to choosing and combining Asana features for workflow success.

Has a winner been declared in Marquis vs. Bastien? I say they’re both winners, as are all readers who benefit here.




While I agree this could be confusing, I also consider that a task will always be opened at one time before done, so people will see the context (top of the task pane). But don’t get me wrong: I’d love to finally see the project appear on subtasks in My Tasks to finally put an end to that bloody debate :sweat_smile:

Unless different people handle those subtasks, and then you end up with people all lost because of the point above ^^

100%, that’s why it is hard to give best practices because they don’t always apply, but that’s also hard to list all the possible variables coming into play :sweat_smile:

I was pretty sure from the get go that no one will win, especially on this complex topic!


If a task has a ton of subtasks and it’s getting confusing to track or view, I will add the subtasks to their own separate project where they then operate as their own “main task” while still being a subtask in the original project. I find it’s easier to manuver to that new “subtask project” to see what still needs to be completed, and they can then be separated out into their own sections if needed to make things even easier to view and tackle. This will also will show the subtask as attached to a Project in your My Tasks so it’s been a great workaround for me!


That’s a very interesting idea, subtasks are still accessed from the main while having an entire project to play with… How do you make sure you don’t forget any + do you multi home one by one (no bulk edit on subtasks)?

Your note about subtasks lacking navigational clarity/context in the My Tasks view is something I immediately noticed was a major issue when I came in to my current org. My workaround for this, because of how we use projects on my team, is to include a code or nickname (1-2 words) that I put at the beginning of the subtasks.

E.g: WTW HTML #1 (which for us means World Trade Week Email 1 [out of 8]) for an email campaign. We have a more waterfall workflow for many of our deliverables and there are a lot of players involved in each element, so this helps everyone know what their (sub)task is about without having to think too much. :slightly_smiling_face:

Writing out a subtask fully, it may look like: WTW HTML#1: Design & share review link > WTW HTML#1: Feedback from [department] > WTW HTML #1: Export design to HTML and code in Pardot… etc. The way we use projects, the project here would be World Trade Week 2023" and would encompass all marketing collateral. So each email, social post, etc. would be a task. And the subtasks become like a workflow.

1 Like

Sometimes I will manually multi-home the subs by bulk selecting them, but the majority of the time my subtasks are created through Rules triggered by Fields. When I set the Rule up in the main project, I’ll add the subtasks that I want to populate to their subtask project right from the there, so they will automatically route correctly to the subtask project once that “create subtasks” rule gets triggered!


Love the convo. Not sure yet where I stand on it, because I feel subtasks have a fatal design flaw that prevents more casual users to naturally interact with them (and prevents me from utilizing them more when collaborating)

That would be the fact that when you click on the subtask, it treats your click as if you are trying to edit the title, instead of bringing you into the subtasks details.

As you probably all know, you have to click on the chat bubble icon to access the subtasks detail pane.

I feel the average casual user isn’t even aware a subtask can be clicked into… only the more curious ones.

I also would prefer subtasks to show the “Project” by default as opposed to having to “tab+p” or click the ellipsis menu.

Great conversation guys. I agree not to go too deep on the layers of subtasks.

Also, don’t forget to use the shortcut Tab + N to create sections to organise your subtasks!