@Peyton_Lee can you help us understand what logic is determining which project section is expanded by default when viewing a given task’s details?
I can’t seem to figure it out.
At first I thought the default expanded section was the project I was viewing the item in. And that may be the case to some extent, but that’s not the case when viewing the task from the Timesheets table.
All tasks in our workspace live in two projects at minimum. So every task shows up twice in the Timesheets view. However, the same default expanded project section is the same for the task regardless of which version of it I click on in the Timesheets tables.
Timesheets Table Example
Pardon my crude mockup here. I can record a Loom if it helps.
Name
Mon
Tues
Wed
…
Group Fields Expanded
Project A
0h 00m
0h 00m
0h 00m
–› General work on project
0h 00m
0h 00m
0h 00m
–› Task A
0h 00m
0h 00m
0h 00m
Project B fields expanded
–› …
Project B
0h 00m
0h 00m
0h 00m
–› General work on project
0h 00m
0h 00m
0h 00m
–› Task A
0h 00m
0h 00m
0h 00m
Project B fields expanded
–› …
Perceived Inconsistencies
Some tasks in the same project have different project sections expanded.
Some tasks in the same project don’t have any project sections expanded.
Collapsing/expanding a project section doesn’t seem to persist when returning to the same task at a later point.
Multiple instances of the same task record in the Timesheets table show the same default project group expanded regardless of which version of the task I select from the Timesheets table.
It has now been over a month since @Peyton_Lee has given us an explanation about these changes. Despite most of us asking for a way to go back to the original view we still have gotten no response as how to. This is a disappointment.
Due to the latest UI, where a task’s projects are collapsible sections, we are seeing the same field appear multiple times on the task. This has made things confusing at the top area, and the overall task longer to scroll through.
They are same field (in our organisation library), that is if you change it within one project section, it changes in the others. That said, there may be fields that only exist in one of the project, which mean it’s important to have all project sections expanded for visibilitiy…
Multi-project tasks needs to be considered as part of this UI change.
I want to support the discussion here. I believe this update is disruptive and adds extra unneeded time to working with an a task in a project. There should be a way to either disable this feature or revert back to where inherited fields and related projects are automatically shown.
Thanks for sharing the additional context, Peyton, and for the work your team is doing to improve the task pane.
One thing I want to note is that I haven’t been able to fully test this in my daily workspace yet because the update wasn’t rolled out to my specific instance, while many of our other users already have it. So my perspective is partly based on what I’ve seen from their experience.
From our workflow perspective, one of the most powerful aspects of Asana is the multi-homing capability. Many of our tasks intentionally live across multiple projects, and we rely on being able to quickly see all of the custom fields that apply to a task regardless of which project they come from.
The main challenge we’re seeing with the new approach is that the same field appears grouped under each project, which creates duplication and makes the task pane harder to scan. In our case, the previous behavior worked better because it allowed us to see all fields applied to the task in one unified view.
If I could suggest improvements that might add more value without losing clarity, they would be:
More flexibility in how the task pane can be organized
The ability to sort or group custom fields manually
A quick search or “find field” option for tasks with many fields
Another idea that could be interesting to explore is allowing custom fields to be applied based on the task type rather than strictly on the project the task belongs to. In many workflows, certain fields are inherently tied to the type of work being done rather than to a specific project. If fields could be associated with a task type, those key fields would remain consistent regardless of which project the task is added to.
This could also help reduce the need to add the same “global” fields across many projects. Instead of attaching those fields to multiple projects, they could be attached to the task type itself, ensuring that the most important fields always travel with the task across projects.
Overall, I believe that controls like these would add a lot more value to the task panel and the overall custom fields experience.
We are rolling out the new task pane view to all users today, March 18.
While we understand that any shift in workflow requires an adjustment, this update is essential for managing complex work. By grouping fields by project, we provide the contextual clarity needed for tasks that live across multiple workstreams.
We have been listening closely to your concerns and have already implemented several changes to improve navigation:
Within a project, Asana now remembers when you’ve expanded the fields table so your view stays exactly how you left it – even across tasks.
We’ve moved sections to the header for each project, so that you can change a task’s section without expanding individual projects.
We’re continuing to iterate on the task pane experience based on your feedback, including work toward:
Easier ways to expand/collapse multiple projects at once.
Making fields that are shared across projects more obvious and visible.
Raising the current field max limit on the task pane, so that you can see more fields total.
Thank you for your candid feedback. We’ll continue to monitor this thread and share every comment with our PMs as we work together to refine this experience.
Adding our voice to the frustration here. The update has just hit our environment, and it is highly disruptive. While I appreciate the minor iterations mentioned above (like remembering expanded tables), they don’t solve the core issue.
We rely completely on multi-homing. By separating fields by project rather than keeping them consolidated in a single, default-visible list, this update creates massive friction and hides vital information from our team. If a unified field list isn’t restored as an option, this platform will no longer support our workflow, and we will be forced to initiate off-boarding.
Hello, I would also like to echo the frustration with the new view. Like previous posters, I can see the benefit of this view for some use cases, however, we multi-home all tasks and use the same fields across all projects. It does not make sense for us to have to open dropdowns in order to view fields, or scroll past redundant fields in order to get to the task’s description.
Being able to toggle back to the previous view would be enormously helpful for our workflow.
I can see the value of organizing fields under their parent projects. This is definitely helpful for designers, but it could overwhelm general users. Unfortunately, these accordions with their default collapsed states and inability to retain state across different instances and sessions have added extra clicks and friction to nearly every transaction for the majority of my colleagues.
Consider providing users with a choice to select the view/experience that suits their workflow best.
Consider a default view of expanded with a “collapse all” control near the top of the task, or at a minimum, add an “expand all” control as a compromise for the default view of collapsed.
Let users opt out of A/B testing experiences after an appropriate period of time for data collection and capture opt-outs as feedback.
@Vanessa_N, this is the key problem for me and I imagine many other customers that rely on a lot on multihoming.
It would be great if all fields that are shared across multiple projects we consolidated into a single unified view that remains visible by default.
Doing so would dramatically reduce redundancy, cognitive load, and system load caused by having to expand every project field section, every time, in every context.
This update finally hit my Asana workspace and within the first few minutes, I felt I have been clicking 10x times more than I usually do.. to constantly expand sections of fields that would previously be visible
You captured everything my team and I have talked about this morning perfectly. We are the power users on a larger team, but the rest are general users and we were already struggling to help them understand the workflows and processes. This update has sent all the hours we’ve spent trying to train them into a spiral.
I received a notification that my response around how the post by Vanessa made me and other customers feel and was told that my response was “offensive”.
I want to address this situation directly, as I believe important context has been overlooked.
While I understand that my response may have come across as strong, I’d ask that you also review the post I was replying to. The tone of that message was dismissive and disrespectful toward your customers, and my response was a direct reaction to that experience.
I’d also encourage your team to review the broader customer feedback surrounding your recent changes. There appears to be a significant and consistent pattern of concerns that, if left unaddressed, could have a real impact on customer retention and your company’s reputation.
As paying customers, we expect to be treated with basic courtesy and respect — particularly when we are already navigating frustration around product changes that affect our teams and businesses. That expectation was not met in this instance.
I hope you will review the original post in full context, take the appropriate steps internally, and use this as an opportunity to strengthen — rather than damage — your customer relationships.
I remain open to a respectful conversation and look forward to hearing how you plan to address this.
Really dislike this new feature. It takes more time to manage custom properties now and to see what’s important to me on a task. We don’t have any desire to have different custom properties on the same task depending on which project the task relates to (though I understand some orgs may). Our org has standardized our Asana processes, dialing them in tightly and this is completely unnecessary for us. At the very least, we should be able to auto-collapse it, but for Asana users who add tasks to more than a couple projects, this would remain an eye sore. Ideally, you could make this an optional setting that we can keep deactivated. Always appreciate Asana wanting to improve the system! But this new task view is a nuisance.
Welcome to the experience…the sheer amount of frustration I’ve been experiencing with this change over the past 38 days has been pushing me away from Asana.
This is the first time in a long time I’m feeling actual aversion to the product and has caused me to move more and more of what I normally keep in Asana to another tool I use.
