Subtasks now show parent project and fields in the task pane ✨

[Olha_Vintonik]

Hi Asana Community,

Today we’re shipping an improvement many of you have asked for: subtasks can now inherit the project and custom fields of their parent task, and you can see and edit that context directly from the subtask Task Pane — up to five levels deep.

What’s changing

When you open a subtask, its Task Pane now reflects the project and fields from its parent. This means you no longer have to navigate back up the task hierarchy just to understand what project the work belongs to, or to fill in the right custom fields.

Here’s what that looks like in practice:

• Project context at a glance. The parent’s project is shown in the subtask Task Pane so you always know where the work lives.
• Custom fields, ready to fill. Your parent task’s custom fields now appear on the subtask automatically — just set the values that are relevant to that specific piece of work. Values are independent, so a subtask can be “High Priority” even if the parent is “Medium.”
• Works across levels. This inheritance works for subtasks up to 5 levels deep.

What this release doesn’t change (yet)

We want to be transparent about scope. This update is focused on the Task Pane experience. Subtasks don’t yet appear in project views like Timeline, Calendar, or Dashboards, and they aren’t picked up by Rules or reflected in My Tasks groupings based on inherited project. We know those are important — they’re on our radar as the next step.

A note to our community

This is a direct response to feedback you’ve shared over the years, including the long-running thread that started back in 2017. We’re grateful for every use case, every reply, and every nudge. This release is a meaningful step, and your continued feedback will shape what comes next.

• Allow to automatically add subtasks to project

The update is rolling out over the coming weeks on web. As always, we’d love to hear your thoughts in the thread below!

[Leigh_Flynn]

I can see how the context this change provides could be helpful, but in my case, it’s providing far more confusion than clarity.

My subtasks are often multi-homed to projects for other teams’ use with specific and limited information selected to be show in those projects.

What is the purpose of showing 50 custom fields that are empty because they are critical to the parent task’s project, but are completely irrelevant to the subtask? Updating those fields within the subtask does not add context to the subtask, nor does it (to my understanding) automatically populate the field in the parent task. Those fields are just taking up a huge amount of space with occasional information peppered in, which makes that information even harder to find.

The view of the parent task’s fields should have an option to omit any custom fields with null values, since the values the subtask is intended to inherit are chosen when the subtask is created. This would help clean up the view significantly, as well as prevent it from appearing incomplete.

If nothing else the “show inherited fields” wording should be more reflective of the fact that it’s showing all the custom fields belonging to the parent task, and not just fields whose values are inherited by the subtask, but not included in the subtask’s immediate project.

Additionally, it makes far more sense to me to show multi-homed and parent’s project custom field information presented as a table with the projects each field lives in as a column to the right (as it is in list view) rather than as toggle-open categorization by project. That would allow the key information – the contents of the custom fields – to be prioritized over where that information happens to live, and could also potentially eliminate the duplicated fields situation so many people have been struggling with.

Finally, and especially with the addition of all the parent task’s multi-home locations to the list, there should to be some way to tag a “home” project, or a prioritized list of projects accessible according to the user’s permissions, to each task and subtask to determine which project’s information is at the top of the list when a viewed from an Inbox or a link, where it currently defaults to the most recent project the task was added to.

[Tetsuo_Kawakami]

I believe this update presents both merits and demerits. In conjunction with the feedback provided below, I deem it imperative that appropriate improvements be enacted.

Updated view of projects and custom fields within tasks needs improving

Hello, I’ve refreshed my asana this morning to see that the way the list of projects and boards within a card is shown has been changed. Before, you could see the board location for the card within each Project at a glance, now it has become collapsable. As someone that works across multiple departments and is managing the output of dozens of tasks a day, this feels like a step backwards. I understand this is to allow a clearer breakdown of what custom field is found within each specific proje…

[Jan-Rienk]

That’s awesome @Olha_Vintonik !

@Olha_Vintonik

… and they aren’t picked up by Rules or reflected in My Tasks groupings based on inherited project. We know those are important — they’re on our radar as the next step.

Awaiting in eager anticipation!

[Florian7]

I completely agree with Leigh here.

While I understand the intention behind the update, I think it would be much better if users could decide themselves how much information they want to see.

For me, the new behavior where the main project is constantly expanded is also very frustrating. It creates way too much visual clutter and makes the interface feel overloaded — especially when managing many tasks and subtasks throughout the day.

Honestly, the older interface felt much better because it was more minimalistic, compact, and easier to scan quickly. That simplicity was one of Asana’s biggest strengths.

More context is not always better if it hurts readability and focus.

Please consider adding:
• a compact mode
• the ability to collapse/hide inherited fields by default
• or simply more control over what is visible in the task pane.

Different users work differently, and having more customization options would make the experience much better.

[Ben_Daron]

Our actual time field is missing from sub tasks now. I’m guessing this is related to this roll out? The parent has actual time enabled, so I’m not sure why this isn’t showing.

Also, does this mean if a parent task has a value of “medium” priority and we create a subtask, it will have a priority of “medium” set by default but can be changed? I’m not quite following how the inherited fields work or what’s changed (other than our time tracking is missing).

[ka_nishiyama]

Regarding the changes to subtask specifications (and Updated view of projects and custom fields within tasks needs improving ):

If you have a deep understanding of Asana’s features, and utilize custom fields and multi-homeing extensively for management, these changes might seem like a significant disadvantage.

Conversely, for ordinary staff members who simply manage their daily tasks efficiently, the UI has become much easier to understand, and I think they’ll be pleased.

(In my case, I might be closer to the latter.)

[Richard_Parke]

Asana, When “many people ask” for a feature, what about those that do not want that feature? Why are you not considering making something a feature-option? This new workflow has removed the ability to assign a project to a subtask individually, and give it a section. This is an important workflow to us that disappeared one day recently. Please give us the option to set it back to the original way.

[lpb]

@Richard_Parke,

@Richard_Parke

This new workflow has removed the ability to assign a project to a subtask individually, and give it a section.

I’m able to do that with the “+” button after “Projects”:

Does that not work for you?

Thanks,

Larry

[Richard_Parke]

Hmmm… I’m a little confused, because sometimes I see it…

And other times I don’t

I’m specifically referring to the ability to change which Group inside a board it is in. In the screenshot above, the group is “Active” - but I don’t see it for the second board.

It appears it is inheriting now. So I can’t change the group becuase of the nature of the inherit.

[lpb]

@Richard_Parke,

This is a confusing aspect of the recent change; let me try to explain.

You’ll now see a subtask’s associated project either because:

1. it’s now showing just by virtue of it being a subtask of a project, or
2. it has explicitly been added to a project.

In the case of #1, you won’t see that project’s section.

In the case of #2, you will see that project’s section.

Nothing changed about the ability to make that explicit homing to the project. You can do that with the “+” as I mentioned, and that still operates as it did before.

I hope that helps!

Thanks,

Larry

[Richard_Parke]

Thanks Larry. To clarify, yes, I do see you can add a project. Here’s what’s different than cause an issue for us. If the parent task is in a certain project/board, you cannot individually list the subtask in that same project/board separately AND choose which section it is in separately from the parent task. I get why some wouldn’t use this workflow, but let me explain the scenario.

1. We use project boards for each of our developers (to allow for collaborative work, which Asana doesn’t provide with the typical “Assignee”).
2. We have a dev task, and it is on a Jr. dev’s board AND a Sr. dev’s board, as they are collaborating on the task together. Imagine the parent task goes into QA.
3. We create subtasks for any QA items and keep them associated to the parent task.
4. The Jr. dev needs to remediate the QA, and the parent task is still on their board. It is now impossible to put the subtask on their board in addition to the parent task.

This has been our workflow for years, and suddenly, we are no longer able to do that. It is continually frustrating that Asana finds a workflow and makes it THE only workflow that EVERYONE must use. Teams are dynamic, and each team is different. Asana assumes that every time is the same, and they know what’s best for their workflow. A better way would be to allow teams to choose what is best for their organization. This might be a little more challenging to support, but with proper documentation, and training tools, implementing features like this are useful for those in the community that ask for them, but does not affect those users who are not asking for the feature. Just because a certain percentage of the community asks for a new bell or whistle, it doesn’t mean that everyone needs it. Just sharing our perspective, which others on this forum have also shared in the past. We like Asana, but are increasingly frustrated with the recent changes being made.

[lpb]

I agree and have been advocating Asana be more liberal with settings for cases like you describe.

In order to help me understand, please confirm this is your use case:

• t1 qa task [in project QA]
  • t1s1 qa subtask 1
  • t1s2 qa subtask 2
  • t1s3 dev subtask 3 [in project Sr. Dev and project Jr. Dev]

Please explain your point #4:

• I don’t know what “remediate the QA” means
• Whose project(s) do you mean by each of the two “their board” references?
• Which of the above subtasks are you referring to with “the subtask?”

[ka_nishiyama]

Based on some testing, here’s what I found:

When creating a subtask:

• The parent task’s project(s) are inherited.

• The parent task’s custom fields are inherited.

• Assignee, due date, etc., are not inherited.

• The project(s) inherited from the parent task cannot be deleted (using the X button).
  

  

• Can “Remove as subtask”, the registered project of the parent task is deleted. but the parent task’s related projects are deleted.
  

  

• When setting a task as a subtask of another task, the parent task’s project settings are inherited.

[JFrentz]

Asana’s first decade

Asana stood apart for a decade because of a clear design idea: teams and organisations could be accelerated by digital interfaces built on one-size-fits-all fundamentals plus adaptable models. The base layer stayed simple and predictable. Each organisation adapted the parts that needed to fit their reality. That balance is what made Asana scale.

Much of that discipline came from Justin Rosenstein and the founding team. Less is more. Clean, simple, useful. It’s one of the core reasons many of us moved entire organisations onto it.

Asana has lost that balance now. Mentally overwhelming architecture and decisions are forced onto every user, regardless of whether the change fits their reality.

The departure: January 2020

The first significant departure from that approach that I recognised was January 2020, when subtasks started inheriting parent custom fields. @Jonas_O opened a thread — Make Custom Fields on subtasks optional. I supported it. We had multiple organisations on Asana and the change was forced on all of them without warning.

In that same thread, @Phil_Seeman pointed out that the inheritance wasn’t really the feature. It was a consequence of shipping subtasks in list view. Once subtasks appeared as rows in a project list, the project’s columns had to accept input, so the project’s fields ended up on the subtask.

The user need was real: surfacing fields from related work. Users had been asking for custom fields on subtasks. Multi-homing already solved it — add the task to the projects whose fields you want, use sections to categorise. The honest problem with multi-homing was custom field ordering, raised by @Jon_Jessen back in March 2019, still not resolved.

A parallel request, to surface more subtask levels in the main views, has been there since April 2020.

The right answer in line with the philosophy would have been to fix multi-homing’s ordering and make composable structures stronger — keeping inheritance decisions in the adaptable layer where each organisation could opt in.

A simple fix, even now

Add a per-project setting controlling whether subtasks inherit that project’s custom fields, with an organisation-wide default.

• Opt-in at org level
• Override per project

This puts inheritance back into the adaptable layer where it belongs. Brings back the original balance, doesn’t break what’s already built. Same pattern — users control what shows up where — solves the wider field-display issues from the threads above.

The pattern repeated instead

• January 2020: subtasks forced to inherit parent custom fields
• November 2020: dependency field surfaced on every task by default
• December 2022: subtasks added to Timeline, breaking horizontal stacking for Gantt-style plans
• October 2025: a new navigation experience that surfaced paid-tier features in the sidebar regardless of plan
• January 2026: task pane reorganised to group fields by project to “reduce cognitive overload”. Addresses one symptom, leaves the underlying model untouched
• May 2026 (this thread): parent project and inherited fields now surfaced inside the subtask pane, up to 5 levels deep. Asana cited a 2017 community thread as justification — same pattern repeating: real demand, wrong layer

Each of these is a decision that belongs in the adaptable layer, forced into the base layer for everyone.

@Peyton_Lee’s rationale on the January 2026 thread was honest about what triggered the change: tasks increasingly live in multiple projects and the pane became overwhelming. Right observation, partial fix. The pane is overwhelming for several reasons at once:

• Inheritance forces parent fields onto subtasks where they weren’t asked for
• Multi-homing surfaces every related project’s fields by default
• Users have no way to control what shows up where or for whom

@Leigh_Flynn’s reply earlier on this thread describes the same gap from another angle: table-based display, hiding null values, primary-project tagging. All of it only makes sense if users control presentation. Group-by-project on its own is a coping mechanism for a model that doesn’t allow that.

This isn’t a critique of effort. The teams shipping these updates clearly care, and individual updates make sense on their own. It’s a critique of accumulated drift away from a design philosophy that used to be Asana’s defining quality.

---

Our decision

For us this is the decision point. After 10+ years running multiple client organisations on Asana, we are forced to turn to alternatives. The drift is at the level of design leadership now, beyond what the retrofit above can fix. I hope my read is wrong.

AI changes what’s possible here. Each organisation can now have software built to its actual workflow, instead of fitting itself to a generic platform. A wave of these alternatives is coming, solving the same fundamental needs without the inherited complexity.

Transition takes time on our side. But in the new era of team collaboration, where digital capacity becomes omnipresent, Asana needs to pivot right now — or risk losing it all.

Thanks to the people who built the foundation. The first 10 years taught many of us what good work-software could feel like.

[Richard_Parke]

@lpb here has been our workflow up until the recent change:

• Task 1 (parent task) in Project 1 Board, also in Dev 1 Board (multi-homed)
• Dev 1 moves Task 1 from section “In Progress” > “Visual Review” on their project board
• QA tickets are created by QA team as subtasks to Task 1
  • Subtask 1 to Task 1 (QA task) added to Dev 1 Board “Ready” section
  • Subtask 2 to Task 1 (QA task) added to Dev 1 Board “Ready” section
  • Subtask 3 to Task 1 (QA task) added to Dev 1 Board “Ready” section

This workflow is no longer possible due to inheriting. Now we have to make a comment on the parent ticket and link to the subtasks. Tasks get large, and sometimes there’s lots of comments, and it is possilbe to miss things. That’s why we create separate QA tasks, and then those get added to a Dev’s board.

Hope this helps,

[lpb]

Sorry, @Richard_Parke, but I’m not able to understand your underlying issue with respect to the change. It can be hard for me in a Forum and communicating asynchronously to address such things, but maybe someone else can help.

[Richard_Parke]

Larry,

Bottom line… it is no longer possible to have a parent task and subtask of that parent task on the same board but in different sections/groups at the same time due to inheriting the parent attributes.

This is not possible now:

• Parent Task in Project Board > in section “Visual Review”
• Subtask in same Project Board > in section “Ready”

[lpb]

I was able to do that:

I actually did this a couple of days ago and confirmed it had worked. When I just did it a moment ago, I ran into an error about not being to add the subtask (I didn’t capture it) but then when I checked again, it appeared to have worked the way I expected.

@Olha_Vintonik, did you run into this?

Thanks,

Larry

[Marcel_Fischer]

I have been a daily Asana user for 9 years now and this might be the worst update you have done so far.

Often times, I want my subtask to have only one project and I want that expanded. The parent tasks projects do not matter to me.

Now this subtask is filled with dozens of projects, with empty fields (just why), with my actual project that is relevant to me collapsed. I now have to read through the meaningless wall of projects until I find the one I actually am interested in and manually open it to reveal the fields.

If you want to show the parent tasks projects (which I never wanted), why can’t it be visually separated below the actually projects of the subtask?

Please reconsider this updates. It is a major daily annoyance now.