To Subtask or not to Subtask

Maybe it’s me, but the reasoning behind having the home page example be it’s own task vs a section is for feedback. It depends on how many people are weighing in on each task, but I don’t see how breaking it down by header, footer, main mockup, is very conducive to feedback.

I run into this issue a lot - my role spans managing design, video production, events, etc. and it can sometimes become confusing if you break it down into tasks like that, whereas if I have a ‘Mockup Home Page’ task, then I create the small ‘milestone’ subtasks if needed (like, creative brief, etc.) - then the actual feedback back and forth is done on the main task.

If we used sections (and trust me I use them liberally in my projects, I think it would be confusing to casual users as to where to add their feedback. For instance, I’m looking at the header task, and I think about how it needs to also reflect the footer - well now I sent feedback for something that’s not the footer task, etc. and it could get confusing if multiple people are doing it, unless you have very strict plans - so if feedback or comments overlap tasks, copy them to both, etc.

I don’t know, maybe these are problems that have different solutions, but it’s why I find subtasks useful despite the drawbacks.

I do agree on a lot of the other points made here about them though.


I’ve never actually used the example I provided (we don’t break things down that way). I was just trying to illustrate how it could be used. In reality, we use a section and then tasks under that section. No confusion and it’s all easily accessed, nothing is hidden from view, it appears in the team schedule, etc. I literally don’t have a single drawback from doing it that way.

Oh yeah I know that’s not the best example, but my issues run through similarly. I find myself always having to balance logic in Asana with the reality of our use-cases, and feedback/discussion clarity is a big one.

1 Like

We use Asana primarily as an editorial calendar, so each task represents a content item (e.g. news release or video) and the sections are the months of the year. The subtasks are the steps to produce each content item (e.g. get the facts, public social media), which basically would be tasks if each content item were its own project.

If we used sections to group the steps, our list would be thousands of lines long at any given time, and all the steps would appear on the Calendar view.

My takeaway here is that each level of hierarchy in Asana can represent different real-life items, and you have to choose the right setup for your situation. I appreciate having the flexibility that many other platforms don’t provide.


Yep, no arguments here. I was just talking about our own usage. But like I said in my first comment, I find it quite difficult to navigate through the details within subtasks (descriptions, attachments, comments).

I think tasks could be easily improved by adding icons which indicate:

  • If there is a description.
  • Number of subtasks.
  • Number of attachments.
  • Number of comments (including unread comments).

And this would apply to subtasks as well, so that when you’re in a task and you see a list of subtasks, you know what to look for.


I think that’s the biggest thing that would help - improve the UX of subtask icons/notifications.

Such as is referenced here:


This is a good list!. I would also add from my work with the CSV to PDF CSV To Asana Simple List Generator- My Gift To Community - #21 by James_Carl that Asana please have subtasks automatically add the Project of its parent task. The idea of subtasks floating around as unattached to a project causes not only problems for the free report I had written for the community but a general problem on many many uses and searches.


We’re relatively new to Asana as a team, but we’ve embraced it and use it to manage a PD development and delivery schedule. We are working through the use of subtasks and sections. We actually do both. One of the reasons we use subtasks is to eliminate scrolling for tasks with many subtasks. I second (third?) the recommendation to be able to collapse/expand sections.

Also, having to assign each subtask (and sub-subtask) to a project to make it appear on the calendar means that we don’t use the calendar view as much. It’s not worth the extra time to us to have to do that manually.

We too, have set the expectation that all comments and conversations take place on the main task. People leave their progress updates after each working session as well. It’s helping the “higher-ups” stay up-to-date in way that they weren’t able to before.

Overall, we really love Asana (OK, maybe I love Asana more than anyone else in my company at the moment), but it’s helping us to stay organized and on-track. Also, SO.MANY.FEWER.EMAILS. All of the things Asana is designed to do.

1 Like

Love your enthusiasm, @Erin_Hommeland!

Hi, I’m a newbe to Asana @Todd_Cavanaugh 's reflection may be especially relevant.

Note: I personally do like sub-tasks. It fit’s my thought-processes very well, but I also have experience from the chaos excessive use of sub-tasks can lead to from other tools. The issue is not tool-specific i.e., some just handle it less badly.

Here are some reflections in favour of using Asana sub-tasks, even if they don’t inherit anything from the paren (which I’ve come to regard as a good thing b.t.w.).

  • Divide and conquer
    • Task may grow larger that originally thought
  • Great way or organising / structuring
  • Sub-tasks can be assigned to other’s (also true for tasks, but…)
    • But paren-task can be used to group that overall-issue and make it easier for sub-teams to regard only information that’s relevant to the overall issue (the paren task i.e.).
  • Not inheriting project-belongings is something I actually now appreciate. At least in “board” projects. This makes the board less clobbered.
    • If one want’s visibility for sub-tasks, project’s can be multi-selected and multi-assigned (I do agree with @Brian_Kurkjian - there should be some sort of behavioural setting for this).
  • Defining work and structure is IMO far more important than categorisation, at least initially in a project when there’s a lot to do and making order from chaos is in grave need. Time is a factor here. The faster structure emerges, the better.

In case one realises ones sub-tasking frenzy has gone too far, I believe one can merge tasks i Asana (I’ve not tried this yet however).

My favourite reason for sub-tasking in Asana:

Asana has this great ability to make parent tasks into projects AND have the tasks (or more sub-tasks) belong to either, neither or both. This is a really nice feature which I’ve come to appreciate a lot. Because:

  • Sometimes tasks just grow. By having sub-tasks, the 1:st level sub-tasks will automatically be converted to root-tasks in the new project, and (one of) their project belongings will be the new project. I.e. new root-tasks will inherit the parent’s project property.
  • Sometimes a task/sub-task just don’t “belong” for one reason or the other (this seldom occurs in well defined tasks, but is quite common during project start-up), but you only find-out/realise this later and/or you realise that a task is really a project. Either because:
    • It’s to big
    • A task/sub-tasks turns out to be/become a never-ending story, i.e rather a processes as opposed to the originating project which might have a clear goal and a clear time-frame.
    • A task’s time-frame and goal turns out to be different from the project (or unrelated to it), i.e. not a process but yet clearly different in scope nevertheless.
    • You want clearer/different team-definition
    • You want different privacy settings

If you convert, then having sub-tasks is an advantage. Additionally, not having the 1:st level tasks belonging to the original project (default behaviour) will save you the (perhaps minor) effort of cleaning these belongings up.

I haven’t used sections yet (it’s only my 3:rd day with Asana), but I can’t see how these would aid build-up of structure and I think converting tasks to project would not work at all as smoothly. I certainly don’t mind using sections (if they can be used for table project - not come that far yet…) as they should aid in over-viewing all the tasks/sub-tasks anyway. I.m. just saying that sub-tasking have great value and that Asana actually handles them well.

I don’t see an exclusive-or for either of the approachs, except possibly for the more advanced API features/abilities mentioned.

Reflections / thoughts

I guess what I was originally most hung-up about is this: "Subtasks don’t automatically inherit the assignee, due dates, tags, or some other information of the parent task".

I however figured: someone must have given this behaviour a real thought. I agree with the behaviour for all but for project belonging. But as mentioned, I’ve come to appreciate the behaviour and have come to realise work-arounds that will do what I want fairly effortlessly.

My first trial project is already 7 task-levels deep, which is a clear case of risking being borderline chaotic. But I’ve found some extremely valuable tricks for not loosing track of issues:

  1. A task can be a sub-task of one parent-task in one project yet belong to another project than the parent (or both… or more). My first thought was Whut!?. But it’s really great. Those kind of issues are both naturally occurring in my organisation (“needs to be done” issues, but no-one cares enough because they all fall in-between projects - typical issues would be maintenance type of work but there can also be other types much more important)
  • This ability can alternatively also used to emphasise another/alternative visibility/overview. I.e. using Asana projects not as projects, but just as placeholders.
  1. Tasks should belong somewhere or they will easily be lost. To find and operate on them I’ve found the filter “Tasks I’ve Created” combined with multiselect + multioperation very useful so far.
  2. As several already mentioned, always at least bind/assign to someone/something (if not made project-bound from start). That will make the (sub-)task less prone of loosing. But if you accidentally do (which happens to me a lot when brain-storming): see the bullet above and tidy-up afterwards.

P.S. I will try to be less sub-task and task-depth obsessive. Point is taken :wink: D.S.

Cheers and thanks for this great thread/discussion. //Michael


I would upvote the heck out of this suggestion.

Subtasks work beautifully on Trello board cards. I had high hopes for the same in Asana once they launched boards but was left disappointed. A sub task on a card is often assigned to a different person than the owner of the parent task. The limitation in Asana is that the card face only shows the owner of the parent task. Please Asana, show ALL assignees on the card face to make triaging of work across teams more efficient.


Hi @Stephanie_Connolly you can add the Sub Task to the board by adding the Parent Project to the sub task using tab+p then adding the parent project.
Hope that helps.


I’m a project manager at an ad agency, introducing Asana to my team… and subtasks has definitely been the most confusing thing. However, I do find them necessary for certain aspects of our work.

Specifically, when we are routing items for review through different people, we use subtasks. The parent task of “internal review” is assigned to the PM, and all the information & background about the piece being reviewed is set up in that parent task’s description. Then the routing to copy, art, proofreading, etc, is done as subtasks.

By clicking on the parent task, everyone can see the status of the route, and the PM maintains responsibility for making sure it’s completed.

There are definitely pros/cons to subtasks, but I think a few tweaks would improve them greatly:

First, I would like to see an indication in the project list view that a task has subtasks. Even better, would be a toggle to show those subtasks indented and below parent – as is done in the print view.

Second, I would like to be able to add the project’s custom fields to subtasks. I don’t really understand why this isn’t part of the functionality right now – it really hobbles the usefulness of custom fields for us.

Third, the UI should be improved for showing the relationship between subtask and its parent. Not as critical, because over time we’ve just learned where the parent task link is, but for new users it’s very confusing, especially when landing on a task directly from an email or a My Tasks link.

Great discussion – I hope to see more here.


Thanks for the response @Jason_Woods. My comment here re: subtasks may have have been unclear, so let me try again.

In the context of managing an Asana Board project, each card on the board represents a parent task. Let’s say that I have a parent task assigned to Person A, then subtasks on that parent task that are assigned to Person B and C. The issue is that the card face on the Board shows ONLY Person A as an assignee. This is misleading and hard to manage, particularly when you have multiple parent task cards with multiple subtasks across a team of 3 or more on the same Board. All cards “appear” to have only 1 assignee, when in fact, there are multiple assignees.

Trello shows ALL assignees on the card face to facilitate triaging at a glance. Otherwise, with Asana, you have to drill into each card to get a holistic view of ALL assignees involved. I’m hopeful Asana will rectify this because I feel their recently released Board project view is far more useful than task lists. But this particular issue is a real limitation for my organization.


Hopping on a super old thread here but I’ve found a subtask feature not mentioned here helpful so I thought I would share.

If you create a Task Template with subtasks that are have been added to additional projects (some with headers) it will automatically keep those projects when copied and sort them by header. I’ve set this up to have a client project view with the master task, a single project with an overview of master and subtasks for all clients, as well as projects for each platform we use with just the relevant subtasks from each client. I’ve included some screenshots in the below comment to show what I mean. For reoccurring tasks I think creating a task template has helped a lot on cutting down how much info needs to be entered - getting it set up took a minute but now everything happens automatically. I still have some subtask challenges but I found that solved quite a few of my problems.


Hi there,
In favor of sub-tasks.

Our company is dealing mainly as a public sector supplier. We are attending several public tenders every week.
We have a Project called tenders and we put each tender as a task and every process for the the tender as a sub-task. 90% of the tenders have the same processes/sub-tasks. So we have a Template Task that we copy every time we have a new tender.
We do not use Projects for tenders because we have more than 30 tenders running and they get lost in “More projects…”

It would be nice though to be able to use features of tasks on sub-tasks like:

  • Dependencies
  • Custom fields

That’s great, @Giorgos_Noulikas. And I agree 100% that’s a perfect use of subtasks, just like the original post said:

1 Like

I’ve read this thread a few times but I still can’t wrap my head around why one would or would not use subtasks. Given the limitation (feature?) of subtasks not inheriting things from its parent task, I’m not sure why anyone would use subtasks. Does anyone have a guide on how to use subtasks in a meaningful way?

For us, currently on Basecamp but wanting to move to Asana, we use Basecamp milestones as our client deliverables and Basecamp todo lists/todo items as internal tasks to accomplish each milestone/deliverable.

I can get behind Asana’s concept of tasks only (no milestones), and when I discovered subtasks I had a clear path to how to somewhat duplicate our Basecamp structure. Now that I understand subtasks more fully, I’m back to thinking Asana cannot work for us. What I had hoped was…

Project A

  • Task 1: client deliverable with due date and assignee
    – Subtask 1: internal task with due date and assignee
    – Subtask 2: internal task with due date and assignee
    – Subtask 3: internal task with due date and assignee
  • Task 2: client deliverable with due date and assignee
    – Subtask 4: internal task with due date and assignee
    – Subtask 5: internal task with due date and assignee
    – Subtask 6: internal task with due date and assignee
    Project B
  • Task 1: client deliverable with due date and assignee
    – Subtask 1: internal task with due date and assignee
    – Subtask 2: internal task with due date and assignee
    – Subtask 3: internal task with due date and assignee
  • Task 2: client deliverable with due date and assignee
    – Subtask 4: internal task with due date and assignee
    – Subtask 5: internal task with due date and assignee
    – Subtask 6: internal task with due date and assignee

Any insight would be most appreciated!


Hi @cfen, I’ve helped a lot of businesses switch over to Asana. There aren’t cut and dry right and wrong ways to use subtasks. I think the best use for them is with “Task Templates” that systematize smaller workflows (like creating a new blog post or marketing email, for example).

For the example you listed, I think you could use Sections for the client deliverable and tasks for the steps to make it happen.


1 Like