Larry,
That’s what I used to be able to do as well. Definitely cannot do that now. Note that the Subtask does not have the section control - where it says “Project Management Sandbox”.
What I expect to see is this:
It seems like we have different release versions. I’m using the web app if that matters.
I’m using the web version too.
Did you do this–add the subtask to the parent task’s project first? That’s what affords the option to place the subtask in a section in the project:
The “The parent task is already part of the project” is a helpful tip, but might also deter some people in your position from going ahead and adding the subtask to the project even though it’s (partially) there already.
Olha, in the future, will that be unnecessary to accomplish what Richard wants? That is, the ability to have a subtask appear in the parent project may not require also homing it to the parent project this way? I could see that working, potentially, for a subtask’s inherited project membership showing a section dropdown defaulted to a new choice of something like “No section” as a more elegant way of handling this…maybe.
Time tracking is now a disconnected field for all subtasks? Please advise whether this will be corrected; as it stands, in order to make the time tracking field visible on a subtask it must be converted to a normal task and back into a subtask, but doing so brings it into the list view instead of rolled up into its parent task. Our workflow involves milestones for architectural phases, with the work on each phase broken out into subtasks; being unable to track time to this work without extensive manual effort that only results in task lists so long as to be essentially unusable is a huge step down in QOL for this system, especially when we just made the complete switch to Asana for its time tracking features.
I completely agree that this change represents a significant step backward and has introduced a considerable amount of confusion.
I am currently evaluating whether to fully restructure our Asana setup, including creating parallel “shadow” projects to manage workflows through custom dashboards that provide the clarity we need. Under this approach, updates would only be pushed back to Asana when a specific stakeholder requires a particular view.
The new collapsible pane within projects has reduced task visibility and usability. Unless a highly tailored project dashboard is in place, it is now much harder to quickly interpret and act on tasks. Routine actions, such as updating stock levels, now require additional steps simply to locate and edit the relevant information.
I would strongly urge reconsideration of this update. Going forward, it would be highly beneficial if such changes could be introduced as optional feature packages or modular add-ons that organisations can choose to enable based on their specific use cases. This would allow teams to retain stable workflows while adopting new functionality in a controlled and intentional way.
Hi everyone,
I wanted to raise a concern about a recent change in Asana that’s become a significant bottleneck for our workflow and automation. It appears that subtasks are now automatically required to belong to the same project as their parent task. Previously, we were able to separate subtasks into different projects when needed, which gave us much more flexibility in organizing and tracking work across teams.
With this new behavior, it’s becoming quite difficult to manage tasks that naturally span multiple workflows or require tracking in separate projects. This limitation is creating confusion, duplication, and extra manual effort just to maintain clarity—ultimately slowing things down rather than improving structure.
Has anyone found a workaround for this, or is there currently a way to revert this feature or adjust the settings? Any guidance or insights would be greatly appreciated, as this change is having a real impact on our efficiency.
Thanks in advance!
I’ve merged your post into an existing topic where this is being discussed, so please check prior posts for more info, but no current way to revert or fully workaround, but maybe some helpful info…and any updates should appear there.
Thanks,
Larry
Three main issues with this update, causing confusion for task setup and task comprehension across teams:
It’s not longer obvious which subtasks are ‘visible’ in the project, alongside the parent task also being visible inside a project. It used to be extremely obvious, now you can’t tell if it’s just “inherited” the project, or if the subtask is actually sitting in the same project as well. Which is often a direct use we want, but now it’s not obvious if it is or isn’t, hard to manage
The deeper the subtasks go, the more projects that get inherited, often parent tasks are designed to be multi-homed, and subtasks we might want them to be appearing in NO projects, or just one minor project (not inheriting all the projects of all the parent tasks above it, that accumulates to be a lot of noise added to very minor subtasks within subtasks, and that is confusing to the team and is unnecessary
Hi, @Livi_Pearce .
My thought was, “A task needs a main project.” What do you think?
Hey folks,
I’m the PM for the Tasks experience. I wanted to jump in and sincerely thank you all for the candid feedback you’ve shared regarding the recent subtask updates. Reading through your comments helps our team understand exactly where these changes are hitting the mark and where they’re creating friction in your day-to-day work.
We are definitely hearing your concerns, and while I can’t share a specific roadmap just yet, please know that we are actively discussing your input internally. I’ll be back to share a more formal update with this group soon.
In the interest of transparency, here is a summary of the main themes we’ve gathered so far:
Positive feedback:
Negative feedback:
Regarding the custom fields, I want to highlight that these appear empty by design. This allows you to fill them in based on the specific needs of the subtask, for instance, a subtask might have a different priority or status than its parent. We felt that automatically syncing all values could lead to even more confusion and less flexibility.
Ultimately, the reasoning behind this design is to ensure that subtasks are no longer “hidden” or disconnected from the data that gives them meaning. As work becomes more complex and cross-functional, having parent-level data visible at the subtask level provides the foundation we need to support more advanced automation and reporting features in the future.
We’re taking all of this back to the team as we look at how to iterate. Thanks for your patience while we work through these next steps!
Welcome, @Livi_Pearce,
I sympathize. But regarding one of your points there’s help:
It’s not obvious, but it’s discernible, as I explained in an earlier post in this long thread:
Thanks,
Larry
Thanks, @Olha_Vintonik, for the update and the continued effort to improve this.
Re your: summary of the main themes we’ve gathered so far, the following were missing even though many posts about them appeared in this thread and in https://forum.asana.com/t/updated-view-of-projects-and-custom-fields-within-tasks-needs-improving/1117994:
Thanks,
Larry
Chiming in that this also breaks my preferred workflow because now I can no longer independently add/remove projects from subtasks to promote them into list views in the parent project and other projects. To move away from this would cause both a significant hit to our workflow itself, and hours to re-tag things to stand up something inferior to me.
Thank you for this summary. In addition to the response Larry provided, I’d like to suggest the possibility of being able to select which fields are heritable as well as which field values are heritable.
Granted, I have little comprehension of the programming this would take, but from a user point of view, this could look like being able to choose which fields get attached when creating a subtask combined with using the existing variable structure within rules to inherit the values, or a setting within the create subtask action defining which parent projects should apply and whether to automatically add projects the parent task is later added to, or even a setting within the field itself defining whether or not that specific field is heritable.
I think there is an assumption at play here that every custom field and every project exists to provide context to every individual who interacts with the project or task at any and all levels, which is simply untrue. For example, many of the fields in my primary projects are calculations. They exist to evaluate the data in other fields and provide triage or reporting information at the parent task level. Once that evaluation is complete, its the single custom field output that matters, not the half dozen input fields and the overarching formula field that inform it, so there is zero need for any of these fields to exist or be referenced at the subtask level.
Some level of user control, somewhere, is absolutely necessary to ensure that the information everyone is being shown is, in fact, relevant to the subtask. The vast majority of my subtasks are intended for users with extremely limited roles to play in my workflows. Some of those are even reference projects, and not intended for action within Asana. Giving everyone all of this information and 50 empty containers vs the 5 they need to see is not only overwhelming for them, but also potentially invites unsolicited and uninformed opinions - they just don’t need to see how the sausage gets made. Because private fields currently cannot be inherited by rule due to the rule requiring guest user rights to implement the inheritance (support case 08982153), I am not able to leverage that feature to help mitigate this issue. Even if I could, it would do nothing to clean up the view for users who do need permissions to those private fields in certain contexts.
I don’t think that’s the case, @Silvaire. See my earlier posts in this topic for details.
Thanks,
Larry
I used to be able to use Asana to have this structure:
Parent Task: Project A
..Subtask X: OR Project A or Project B
The default of null meant it did not show up in any of my list views as a task. However, if I added that specific subtask to Project A, it now appears in list view and can be manipulated by all of the project fields that can be assigned to it. This is the workflow I rely upon and it is this workflow that has seemingly broke in the last day or so.
My existing tasks with the structure are fine, but any new ones I create automatically add the parent project to the subtask project. Furthermore, the project setting no longer determines whether they show up or not in list view. They don’t.
Please bring back this functionality back as an option in the worst case.
The Actual time field has historically been directly bound to the Estimated time field in the task pane. They were always at the top. This made sense to me because it’s reasonable that they should be next to one another and Actual time is something a user will likely want quick access to if their organization tracks time.
But now it appears in this “Disconnected fields” area for subtasks whenever that subtask does not live anywhere as a parent task.
Someone reviewed that ↑ and said, “Yeah. Looks good. Let’s ship it.”
Moreover, if it does live somewhere as a parent task, only the project dropdown where it exists as a parent will show an Actual time field.
The changes made the the way custom fields are displayed in the task pane were bad enough and I’m pretty sure this is a byproduct of the design decisions made there. Of which the overwhelming majority of feedback is negative:
I’ve long been an advocate of subtasks inheriting their parent task’s project. But the solution here is missing the mark.
Like others have suggested, I think what’s missing here is the concept of a “primary/main project” but in order for that to work, it would need to be something an individual user can set for themselves.
And this is largely because Asana does not have a way to display tasks across different projects in a single view that has the same functionality as we’re used to in projects with respect to list view, board view, etc. including filters, group by, sorts, field order arrangement, field width customization, etc. Something I touched on here with respect to the board view:
I preferred a world where I saw all of the fields I wanted to see in a given context without having to click a bunch of stuff to figure out where it is first.
I’m so glad I found this thread, as I had emailed Asana support about this and they didn’t even acknowledge that a change had happened here.
We have flows that add subtasks themselves to projects. Now there’s no way to see this, as it looks like every subtask has been added to all projects of the parent task when they really haven’t been.
Is there a plan to solve for this? This new update causes so much confusion because of this, as the only way I can tell if a subtask is actually in a project is to go that project and look for it. We just lost a major piece of visibility that we’ve always relied on.
Hey @Skyler, regarding the Actual time field, you may want to check this related post:
Thank you @lpb - this is helpful as I can see the difference now. However, this still doesn’t seem intuitive at all and, if I couldn’t figure it out (as an Asana super user), I’m thinking the change management for this will be very hard.
Also, the order of it seems really weird. In the example below, the first project I see is the “Brand & Content Queue”, but the subtask isn’t explicitly in that queue. It seems like it should list projects that the subtask is in first and somehow they provide a better distinction between the projects that are just inherited.
