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

[lpb]

Yes, lots of potential improvements for sure. I was just conveying what is available right now, which is not ideal.

[Tony_Gallina]

With the recent update, every subtask now shows all the projects that the parent task is in, instead of only the projects that the subtask itself belongs to.

This creates two big problems in my day-to-day use:

1. Confusing task organization
   When I open a subtask, I can’t quickly tell which projects the subtask is actually part of. I have to stop and mentally sort out “Is this project from the parent or from this subtask?” every single time.

2. Extra time on every subtask
   That added cognitive load and checking slows me down whenever I’m reviewing or organizing work. It makes it harder to trust what I’m seeing at a glance.

Workaround:
None right now. I’m just gritting my teeth and trying to work through the confusion.

Request:
Please consider:

• Reverting this change, or

• Adding a clear visual distinction / option so subtasks only show the projects they directly belong to.

This small UI detail has a big impact on how fast and confidently I can work in Asana.

[lpb]

@Tony_Gallina,

I’ve merged your post into an existing topic where this is being discussed.

Thanks,

Larry

[Margaret_Hiatt]

Asana can’t seem to get this figured out. I do not want the custom fields of the parent task in my subtask. Every project I have now is functionally confusing with the latest update.

Before the parent task custom fields were hidden, in the task but hidden by default. Now we have a feature upgrade and all 20 of my projects are confusing. Subtasks are forced to have the parent task listed as a project and it is listed first. Which in and of itself, is not necessarily a bad thing. The bad thing is that the custom fields in that project show up in the subtask expanded and the subtask custom fields show up at the bottom, collapsed. Plus the information in the parent task doesn’t even transfer down to the subtask where it might be useful as reference. They are completely new empty fields that look like they need to be filled out and completed. The stuff that needs to be worked on? Hidden at the bottom.

Can I set custom fields to not propagate to subtasks? No

Can I set the parent project to default to collapsed at the subtask level? No

Can I disconnect the parent project? No

Can I reorder the projects in the subtask so the subtask project is at the top? No

I use custom fields as checklists. Processes are 40 - 90 steps long. Some of the steps are minor (move documents to a specific location) and might take seconds. Some steps are more involved and might take hours to complete. Some steps are situational dependent and don’t need to be done at all. I use rules and the toggle of a custom field toggle to create a subtask with its own custom field checklist. I use sections to give a high level overview of where a task is in the process.

All the steps listed as custom fields are there because they must be done. With such long processes it is easy for people to forget something. Having a checklist to toggle makes all the difference. And different people are responsible for different activities. One person is charge overall so having a main task with someone managing and other people working on subtasks works.

I guess I have 2 options.

1. Get rid of the majority of the custom fields and create projects where each task would have 40 to 90 subtasks. Basically map each existing custom field to a subtask. Plus a rule for each to decide if it needs to be created for this particular task. Then instead of assigning one person to a subtask with the list of things they need to work on I can scroll through all the subtasks and pick out the 5, 10, 20 subtasks that they need to work on.
2. Create 90 custom fields to replace the subtasks. Create rules to change the custom fields based on other custom fields. If A is Yes then B - E can turn to N/A. Then assign each task to the person who needs to work on the next batch of activity. Of course that means that multiple people can’t work simultaneously since only person will have the task. Plus having to watch that people don’t complete the task when their work is done instead of reassigning it the next person.

Of course there is a 3rd option - create a project for each task. Currently that is 77 projects. That does not include any tasks that I am working on personally. Manage oversight on these with portfolios. I’d have to create 3 or 4 additional portfolios and then make sure every time a new project was created it got added to the right portfolio.

At this point I am frustrated. (Lots of other words come to mind but NSFW) So much work just tossed out the window.

[lpb]

@Margaret_Hiatt,

I sympathize with you.

I’ve merged your post into an existing topic where this is being discussed.

You may also want to review and vote for this topic:

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…

Thanks,

Larry

[DIANA_FERRERA]

Since the latest release, subtasks automatically inherit custom fields from their parent task — and this is breaking a workflow I built.

My setup: the parent task lives in one project, and its subtasks are multihomed across different department projects depending on who owns that piece of work. With this change, subtasks are now being added to every project the parent belongs to, not just the ones they were intentionally placed in. And the worst part is that I can’t manually remove that unwanted multihome from the subtasks — there’s no way to undo it through the UI.

I think this should be something the user can choose, not a forced default. Teams structure their work very differently, and this kind of change without an opt-out breaks a lot of existing setups. A simple setting at the project or task level — something like “inherit parent custom fields: on/off” — would go a long way.

In the meantime, does anyone know of a workaround? a setting I’m missing, anything. Would really appreciate it.

[Skyler]

@Olha_Vintonik - I believe this change also broke the “parent task” status a subtask receives when multihomed into another project itself. I detailed this further in this feedback/bug report:
Multihomed subtasks not properly recognized as parent task in multihomed project.

[Richard_Sather]

Curious if anyone is running into issues where rules are triggering on subtasks, whereas before they weren’t?

I have to go into these rules and manually switch off trigger on subtasks. Before, this was not a problem because the subtask was NOT in the parent task’s project, whereas now it is and is breaking workflows by misfiring rules

[Skyler]

@Richard_Sather

@Richard_Sather

Curious if anyone is running into issues where rules are triggering on subtasks, whereas before they weren’t?

YES! I’m dealing with this too.

[Richard_Sather]

Yeah, this is quite frustrating as it has broken particular workflows, plus we get to see numerous projects and fields that have absolutely nothing to do with our subtasks.

Not great - not just for us but for the numerous customers we cater for - all we’ve been hearing lately is just confusion and simply not the way their worklfows were initially designed for

Kinda feels like Asana has changed the rules of the game during the half-time period..

[Phil_Seeman]

@Richard_Sather

Before, this was not a problem becuase the subtask was NOT in the parent task’s project, whereas now it is

To make things even more confusing, in my testing from an underlying data perspective the subtask is still not connected to the parent task’s project - same as it never was (to misquote the song). Yet there are elements of the Asana ecosystem that now interpret it as if it was, like the rules you mention.

[Emily_Roman]

Hi everyone,

Thanks for your candid feedback on this release, both here and in the related threads. We’ve read all of it, and the feedback has gone straight to the team working on this.

We shipped this update to solve a real problem: having to climb back up the task hierarchy just to understand where a subtask lives and which fields to fill. For a lot of workflows it does that. But you’ve also surfaced cases such as multi-homed subtasks in particular, where it can do the opposite, surfacing a long list of parent-project fields that are empty or irrelevant to the subtask and burying the information that actually matters. That tension is real, and we hear it.

I’ve escalated the issues you flagged with rules, multihoming subtasks and drag and drop to determine what’s working as expected versus what may be a bug, and we’ll follow up in this thread once we have a clear answer.

This release was deliberately a first step, not the finished picture, and this kind of detailed feedback is exactly what shapes the next one. Please keep the feedback coming and let us know if you have any other questions!

[lpb]

Update 2026 06 09: * @Chelsea_C re-tested and corroborated my finding in this post. See Subtasks now show parent project and fields in the task pane ✨ - #58 by Chelsea_C

@Chelsea_C,

I sympathize generally with you and other posters here and have chimed in often in this thread.

But regarding this:

@Chelsea_C

Now, that separation is no longer reliable.
Linking a client-facing subtask to an internal parent risks exposing structure or other workstreams, which is not acceptable in client environments.

I was unable to duplicate this. If this were true, this would be extremely serious and I’m sure Asana would need to immediately address this. But I’m not seeing any new work objects/attributes improperly exposed. Can you be more specific, and show screenshots, and steps to recreate?

Thanks,

Larry

[Ashley_Hobbs]

This 100%! I know there are many forums about rules applying to subtasks (and I was sent to this post / update from one of those and got excited that it was actually happening ). I cannot wait to have to manually update subtask fields that should be done with these rules. Fingers crossed we get this one soon

[Michael_Levin1]

There are many good facts and issues in this thread.

I ask for one hopefully simple change until it is all worked out.

Please have the new inherited project tasks come in collapsed when I open the subtask.

If I want them (which I don’t) I can expand, but now I can see all my associated projects with the subtask and choose the one that is appropriate for me to fill in task fields for this particular sub task.

Thanks!!

[Chelsea_C]

@lpb - Just re-tested this. I am mistaken! The privacy rules are still being held even with the subtask sitting on the internal board. The External Assignee is not able to see parent task information or sub task details. I’ll will remove that comment.

[lpb]

Thanks for re-testing, @Chelsea_C, and glad to hear there’s no privacy issue and we’re seeing the same thing. I updated my earlier post.

Larry