Updated view of projects and custom fields within tasks needs improving

[Richard_Parke]

Hello. We have been using Asana for a long time now. Occasionally you will make changes, that though we feel are unnecessary, and does not improve the workflow, have not been detrimental to that. This new feature that was just released IS extremely disruptive to our workflow.

The new feature separates different project fields into their own drop-down. Previously, all fields were combined into a single list of fields, which was great to be able to assign fields quickly, because the list always displayed. Now, if it is a subtask, it collapses all the projects the subtasks is a part of, meaning you constantly have to click the drop-downs to set the fields. We are constantly getting confused now as to where the data is, and having these multiple lists of fields is unnecessary and killing our efficiency, causing errors at times as well.

I don’t understand the need for this feature… what is it fixing? Is it helping anyone, or just disrupting our workflows? It still ceases to amaze me the “features” that are added that do NOT help workflow. People need options. If a feature like this is going to be released, we should be given an option to use the old layout! Asana can’t really think they know what’s best for all its users, do they?

[lpb]

@Richard_Parke,

I’ve merged your post into an existing topic where you can click the title to scroll to the top and vote by clicking the Vote button.

That topic also includes Asana’s explanation for the change.

I agree with you that more is needed here, probably options, which I’ve advocated for generally.

Thanks,

Larry

[Richard_Parke]

Thank you for the explanation. It still doesn’t help those who do not want to use this feature. This isn’t about just teaching the team a new workflow - every team has a different workflow. For Asana to just implement this and assume that it is the “right” workflow for everyone, is missing the bar. The “contextual clarity” was there before. You’re now creating new confusion by duplicating fields mutliple times in project drop-downs. When fields are shared, it’s now duplicating them in each project, rather than combining them into a single fields list, which is what it seems like most people want. If Asana truly wants to be the tool that people want to use, implement options, rather than just implementing what you think everyone needs. This has been Asana’s MO from the beginning, and time and time again, as I read through forum posts, it seems as though what people are looking for, is options. How much more impactful and industry leading might Asana be if implementing options become the new path forward.

[Richard_Parke]

This is also messing up rules now. It worked just fine before, but now every time I trigger a rule to add a comment based on a status, it’s triggering another rule from another board, and causing multiple comments in the thread. This is really bad… please reset this feature until you’re ready to release it. It’s clearly not ready.

To further aggrevate things, previously Asana removed the ability to remove automated (from rules) comments. So when the automation runs, I’ve got misleading comments being added. We have to shut off all our automations, rendering the feature useless!

[Richard_Parke]

Yes!! So many extra clicks.

[Matt_Albanese]

Agreed with many others. The previous way to viewing linked projects on the card was better. We would appreciate if we could revert back! Thank you.

[ka_nishiyama]

Please divide this threads into multiple threads.

The reason is that it’s currently confusing.

As a suggestion to split the thread,

• Revert to previous settings.
• Modify rule behavior.
• Change the project’s display position.
• Improve the display order of custom fields.
• And so on.

---

It’s understandable that many people have doubts about this change. It’s a situation where a familiar UI suddenly changes drastically, leaving users confused about how to use it.

However, realistically, fewer than 300 people have “liked” this thread. Considering that the Asana forum has over 900K participants and over 30K ambassadors, isn’t that a small number?

Personally, after using the new UI for a few days, I feel that “(at least) Asana is easier to use than before.”

[Keeley_Sylvester]

This is our experience, as well. This update has caused so many extra clicks and more confusion for our users, even our super users. Would love to see this feature reverted or added as an optional setting.

[Stef_O]

Hi, everyone –

I’m Stef; I’ve recently stepped in to lead the custom fields team. I wanted to follow up on the previous updates and share some more context on the “why” behind these changes, as well as what we’re focusing on next.

One of the main challenges with the old flat list of fields was a lack of project context, which compounds as a task is increasingly multi-homed.

For example, let’s imagine a creative asset task that originates in a Content project but is then multi-homed into Social Media, Paid Media, and Legal Review projects. Each project has its own local fields as well as global fields shared between multiple, but not all, projects (e.g., the Social and Paid teams might share fields like “Target Audience” or “Region”).

• Collapsing all of a task’s fields into a single list introduces process risk: a Legal reviewer looking to update a “Legal Status” field might accidentally update a “Status” field belonging to the Paid Media project instead. If the Paid team has an automation tied to that field, like triggering ad spend once the status is changed to “Approved”, a campaign might go live before it’s been finalized and approved.

• Conversely, fields that seem shared might not be: the Social team might update a “Target Audience” field and assume that the Paid team can see it in their project, only to discover later that the field was never added to that project.

In grouping fields by their source, our goal is to provide teams with the clarity needed to see exactly where a field lives – and doesn’t. As projects grow, multi-homing becomes more frequent, and workflows become more intricate, this clarity becomes critical for ensuring that updates are intentional and don’t trigger unexpected automations elsewhere.

We hear the feedback that this shift has added clicks to your day, and we are targeting improvements to restore that speed.

As Vanessa mentioned, we’ve already updated the “See more” and “See less” controls within each project so that Asana remembers your preference across all your tasks; if you choose to see the full list of fields within a project, that view will persist as you move between tasks. We’ve also made it easier to see and manage a task’s section while projects are collapsed. We’re currently exploring additional updates – such as a collapse/expand all button, increased field limits, and better shared field visibility – to further refine the experience.

We recognize that a workflow change like this is a significant adjustment. We’re committed to ensuring that the added data integrity provides a clear, long-term benefit to your teams, and we’ll continue to focus on making this new navigation as efficient as possible. I’ll share more updates here as we hit these next milestones.

[Richard_Parke]

Thank you for your explanation. Out of curiosity, was this a feature request that came in; are there people who do want this feature? It just seems like there are so many who don’t need this functionality you are describing, and it is not the problem you describe. There has never been any risk for us in using this workflow. This isn’t going to be a “just get used to it” or “new things always take time to figure out”… this is a serious time problem for us. It’s already causing not only time added to the workflow, but it’s causing mistakes - which is also a business risk. It seems like what people are asking for here is nothing like has been created. It sounds to me like Asana may need to go back to the drawing board and find a better way to solve whatever problem is deemed an issue, rolling back the work that was done (for now), because the community is telling you that what was built does not meet the needs of your customer base. I hope that is coming through theh frustrated comments in this thread.

Let me share our workflow with you as well, to provide the “why not change it” for us. Because Asana does not allow multiple people to be assigned a given task, we have created Person Project boards. Each IC on our team has a project board. We move tasks into those project boards to allow for collaboration on a task (something Asana does not support, though many other PM softwares do). I understand Asana’s reasoning behind it, but in reality, it’s not the way teams work. We work collaboratively, not in silos. This has been our way around that - by creating additional boards. So when work comes in, the PM assigns the work to the main Project board, but also to an IC’s project board. Person boards only have a few columns, but we follow the same layout/structure for fields throughout (something Asana is good at allowing through global fields). We have a field called “Status,” and the status of a task is the overall status - for all boards. 1 task would never have multiple statuses, regardless if 1 or multiple people are working on that task. The problem this new workflow generates for us, is now we have long lists of fields, and in order to change something, we have to continually scroll down to find. We are continually getting confused as to where the fields are for each board, and what’s worse, subtasks don’t show all the columns anymore. This is a huge problem.

Would Asana consider building 2 ways of doing this? 1 the old way, and the other the new way? That way we can have the best of both worlds. If there are truly some people who want this feature, then they get what they need, and for the many that are chiming in on this forum, we will have what we need.

Bottom line for us - we want to like Asana and we want to continue using it, but some of the recent changes you’re making are not helping that relationship, and we don’t want to move off-platform, but might have to. Please hear your community, and please consider better research before pushing out something as major as this. Thank you,

[Lynn_Morris]

I agree with Richard! This change has caused my team so much extra time with the extra clicks. We went down in efficiency by more that 60%. Now, instead of a quick snapshot view of everything on one task, we are spending time clicking things open.

[Leigh_Flynn]

I agree that the interface is a little clunky, but I do actually like the concept of being able to toggle between different projects’ custom fields lists. I have struggled with opening a task out of my inbox, where the custom fields have previously defaulted to the most recently multi-homed project instead of the project I need to update fields in.

I strongly disagree with the idea of pulling custom fields common to multiple projects into their own section as my organization relies heavily on the order of custom fields being set based on the individual project’s purpose. Pulling the shared fields out of their project-specific order would dislocate them from related non-shared fields. As an example, let’s say a task starts in an Intake Project where we add triage, a part number, printer information, requested changes, etc. before multihoming to an Actionable Project. In Actionable, as the task progresses and we gain more insight and feedback, we add what types of proofs are requested from the printer and the categories the requested changes and any changes added during the process fit into. In the hypothetical “prioritize shared fields” view, Actionable’s proof and categories fields would be completely disconnected, visually, from the printer and requested changes fields shared with Intake.

I wonder if, instead of a list of all multi-homed projects, there could be a single, possibly multi-select, dropdown menu to choose the view, with options for each project’s complete and ordered list of fields (shared or not) and an additional option for a “shared fields” view. Along with the system remembering the set view for each user, this might help reduce the visual clutter and give everyone options that work for their specific use cases, especially if there was a corresponding setting at the project level for default settings to better serve people who only operate in Asana as viewers.

[Stephanie_Cosentino]

I agree with everyone on this thread who is dissatisfied with this recent update. It now takes more time and more clicks to complete a task that used to be quick and easy. It is also very easy to miss critical information when the fields are collapsed. I have been a huge fan of Asana in the past, but after this update, I would not recommend Asana to others.

[Andrei_V]

Our internal teams need different views on the same tasks, so we utilised Asana’s shared fields a lot. For example, the same Status or Client filed is added to our library and exists in different projects to sync tasks across them, giving different teams dynamic, tailored views

After the last update, every project adds ALL of its fields into every task view, leading to shared fields appearing several times

Can I turn this off for our team?
Or can we have shared fields appear separate from project-specific fields to avoid duplication?

This update is very disruptive for our operations, and in my opinion, goes against the previously established logic for shared fields.

[lpb]

@Andrei_V,

I’ve merged your post into an existing topic where you can click the title to scroll to the top and vote by clicking the Vote button.

You can’t turn this off (although I think one person reported that a Support request for that was successful), but we’ve been lobbying for an improvement here and Asana is aware of the concerns.

Thanks,

Larry

[Jess_deCsesznak]

I wanted to come on here and agree with what everyone has been saying. I see the rationale behind this update for certain use cases, but it also makes things extremely complicated for other uses cases (such as ours and many of those who have posted above).

@Stef_O - Has Asana considered the possibility of enabling accounts to toggle this setting on or off on their end (as a universal setting) or even enabling the ability to choose what fields are in the task pane by default? I know that Wrike has that second setting where you can choose what fields actually appear in the task pane.

Most of our tasks are multi-homed in at least 2-3 projects, each with the same 20 fields. So instead of our custom field options being 20 fields long, it’s now 40 or 60 fields long, which makes the experience extremely clunky. Thank you!

[Olivia_Sorokes]

Adding my voice to the frustration! We multi-home tasks in many projects and we use shared fields… it is so annoying to see the field duplicated across the tasks. The old view was great: If you had a task in a project it gets those assigned fields. If you add it to an additional project that has more fields, it inherited those additional fields. The duplication is wack!

[Emily_Lewis1]

This update has been very disruptive to our system. Just before launch, we built a new process that this release has made nearly impossible to use. One of Asana’s strengths is the ability to multi-home tasks, but this update has made that functionality confusing and difficult to manage.

It’s frustrating given the amount of time invested, and at this point I don’t see a clear way around the confusion this change has introduced. Team members outside of the PM group will struggle to know which board they need to expand fields on, and the presence of duplicate fields adds another layer of uncertainty. There’s no clear guidance on which fields they’re expected to complete.

This is likely to create widespread confusion across our workflows and significantly increase help requests. I hope there is a plan to revert this change or allow teams to choose between this new approach and the previous one, depending on what works best for their processes.

[Anna_Jos]

Has anyone noticed how this change also impacts the list view of the projects? We’ve noticed that since this release, subtasks are unable to display field or custom field values when utilizing a project’s list view. When you enter a custom field value or select a drop down value, it clears out from the project’s list view. This includes basic task fields like estimated and actual time. Is this the same for you? Including a screenshot below - all of these subtasks have associated estimated time that is no longer displaying at the project’s list view, for example.

This change is extremely disruptive to workflows we just released to our teams at the start of the year and is harming our user’s sentiment over Asana use. Change management is always challenging, especially in a large team, but these recent releases on top of our workflow changes in Jan are truly causing panic across our teams.

[Ana_Freire]

Hi all,

I’d like to raise a concern about the recent change where custom fields are now grouped strictly by project.

In our workflow, tasks frequently belong to multiple projects, each with its own set of fields. Previously, we had a unified view of all relevant fields in one place, which made it easy to understand the full context of a task across boards.

With the current behavior, fields are segmented by project, forcing us to open and navigate into each project individually to access its data. This introduces several issues:

• Significant loss of visibility across projects

• Increased cognitive load when analyzing tasks

• More time spent navigating instead of working

• Higher risk of missing critical information

Importantly, duplicating fields across projects is not a viable workaround. These fields are intentionally scoped to specific teams or contexts, and replicating them would create governance and data consistency issues.

For teams that rely on cross-project workflows, this change feels like a clear regression in usability and efficiency.

Is this the intended long-term direction? And are there any plans to restore a unified view of fields or provide an aggregated option for multi-project tasks?

Would love to hear if others are experiencing the same impact.