Make Custom Fields on subtasks optional

It’s not a workaround, it’s by design.
Aiming for just one project in Asana seems like an edge case. Why would you do that? Asana is designed for you to use multiple projects. To me, it sounds like you are trying to achieve simplicity in the end by adding the same simplicity to the layers behind. It doesn’t seem scalable to me, maybe you can make it fit now but limiting your structure to just one project like that will make it break somewhere else along the way. Don’t know your background but it’s like fitting a whole database into one table instead of utilizing the capability of having many to sort the data.

Do you want one project with a full overview of PM workload?

We drag and drop planing with unique timeframes based on billable estimates right in the timeline in Asana, for multiple distributed teams. I think you should too. :heart:

It’s better to have complex behind and simplicity in front. Right now our complaint is that we can’t control the complexity in subtask view of the user. What you describe as workarounds are features by design to me and the complexity you try to avoid in the architecture is the solution that enables the simplicity to us.

I think this highlights a difficulty for Asana, to balance feature release, is the direction of the product early simplicity or endgame frictionless simplicity? The power has always been that they have achieved both, not this time.


@JFrentz I think maybe you misunderstood or I was not clear. We do use multiple projects. In fact, our PMO is managing over 180 projects for 2020, each with its own Asana project. All tasks are billable and allocated differently. What I was saying there is absolutely no reason we should need to copy subtasks to a separate project in order to track hours - especially when other platforms offer this functionality out of the box.

I think the point is, every organization has its own use case, so flexibility is key.


It makes total sense to me that it’s useful to inherit certain custom fields in subtasks.
For example, to display custom fields on subtasks you create on the fly you will manually have to add it to either the parent project or another project. Either way it would have to be done each time.
It’s really difficult to get participants in a more complex process to perform this step.
In those cases it’s great if you can define a custom field in a way that it is also applied on the subtasks of tasks within the project. That would be way better than having to create separate “dummy” projects for subtasks so that they can have custom fields.
Unfortunately forcing this behaviour across all of Asana is detrimental. But yes, I totally understand the use case that it can be useful to inherit custom fields.
There WAS a workaround before this change which was recommended by Asana. My process was somewhat inspired by the workaround and now it’s been destroyed.
I now DO NOT have a workaround at all for my problem.

1 Like

First comment on these boards. Just wanted to voice my opinion as well to help out the team at Asana. I see (and enjoy myself) the benefits of showing the subtask in the main list view, and I get the thought on needing to then filter down the parent custom fields down to every subtask, but I think there needs to be an option on each custom field that allows you to select whether that custom field trickles down to subtasks. We’ve got projects with custom fields that just make no sense to be seen on every subtask, as parent tasks and subtasks are, by definition, at a different granularity.

My opinion would be to enable a setting on each custom field to prevent the inheritance of custom fields on subtasks from their parent tasks, and that in the list view, the subtasks should just have blank, non-interactive fields.

As an aside - I really appreciate the way that these forums are built out, the sliding timeline feature to track the issues/subjects by date is really very nice.


Also my first comment here.
People at Asana, you need to see all the comments here and all the likes on the original post.
Here is one of many examples where the custom fields totally mess up the experience, these custom fields has nothing to do with the task:

There must be so many ways that this is destroying the experience for your paying users. Please just make Custom Fields for subtasks optional and everyone will live happily ever after. :grin:


Hi all :wave:t3:

Thank you so much to everyone who took the time to share their feedback with us on this topic! While we know that most of you were excited to see subtasks appear on your task lists, we recognize that having project custom fields on subtasks has created confusion for many of you. In order to minimize confusion, we’re rolling out a new update to hide custom fields on the subtask pane by default! This means that when opening a subtask, custom fields won’t be visible unless you click on “Show more fields”. (See screenshot below)

Please note this update is currently available to 50% of our users and will very shortly become available to everyone!

I’m closing this feedback for now, but please don’t hesitate to reach out if you have any follow-up questions :slight_smile:


Will this be ALL custom fields?! If so, this still doesn’t resolve the problem! I have custom fields on subtasks that are not related to the parent task but totally relevant to the subtask. All this means is users now have an extra click to discover the mess of custom fields beneath!!!


Curious to this aswell. I would like to know this before I mark that as a solution.


1 Like

THANK YOU! Glad to be part of the 50%. It is a huge relief to see clean subtasks once again.

Those will not be hidden by default. Only custom fields “inherited” from the parent task are hidden.


@Val_Kharitonov and @Marie,

I think this may be a simple, elegant improvement to help address the concerns some of us had with the inherited custom fields feature.

However…some questions:

  1. Is there a reason the link is worded as “Show more fields”? I feel it should say “Show parent task’s custom fields”. It’s key to say “custom fields” instead of just “fields” which is unclear. It’s also key to explain which custom fields it pertains to–to make it clear why certain ones have been hidden but not others.
  2. If any of the parent task’s custom fields have values, could you show the fields by default and remove the link?





Ok its nice that you addressed this but it really doesn’t fill the request or wish from a lot of the users here to make the custom fields optional. The fields are still there and will still encourage the users to click “show more fields” and fill them out. I guess if the fields are populated they will be visible? But again the fields are not optional and there will be fields filled out that really are not supposed to be filled out. Sorry for being such a burden for you. But i really think the subtaskfields should be optional from the project settings and greyed out in the project view if they should not be used.


edit: Ok im really halfway happy that you did something to clean up the mess. Still i feel its not really there.


Minority view here…clearly. The way I use Custom Fields, they make perfect sense in Subtasks, and I NEED the ability to have the values different from the parent tasks. Typical such fields are: Priority (with my custom values) and Completion% (ditto). These are all typically different from the parent Task…as are Assignee and Due Date. My Tasks are typically pure action Tasks, as opposed to other types of entities (Customers? Order? Projects?), and Subtasks are logically similar and parallel to Tasks, being different only in being finer-grained. The changes made happen to suit me, and I totally acknowledge the SEVERE disruption that has been caused to a huge range of users.

Could the root cause of this type of dysfunction be summarized as follows:

  • Asana makes questionable architecture and design choices over the years…seemingly without realizing it
  • Users build workarounds like a massive yet rickety scaffolding, doing what they have to do to get their work done
  • Users complain about the work to build and maintain these spindly scaffolds
  • Asana get the message and “fixes” one bad decision from the past, with seemingly no thought for the variety of use cases or the vast array of workarounds present, then pushes it to users with ZERO notice! Hence kicking out supports all over the place
  • Superusers erupt in shock and anger as their productivity tool becomes a source of confusion, frustration, and downstream user horror.

Asana, please. Think first; push code only after due consideration. And when you fix the issue complained of in this thread, kindly don’t break something else in the opposite direction. I’ve never used any other software that had my head spinning with all the UI changes, let alone data model changes.

And if you really REALLY insist on dropping bombs, would it be possible to give at least a bit of heads up? Keep in mind people posting here are the superusers, many of whom are the face of Asana and the advocates and trainers of Asana in our org.


Hey @Stephanie_Oberg !

Nice to have your view at this. What im hearing here is that you also would like to have the setting at a project level instead of in the subtask level. It seems like for you to have the fields that you like on a subtask a option on the project level would help you to decide “these custom fields will be visible on a subtask” sortof. When reading most of the commets here. Most of the users use custom fields on subtasks. Just not the same cusom fields all the time. So an option to make the custom fields optional on the project level seems suitable. Btw Assignee and Due Date have always been different on subtasks from parent task so that wont affect you from the change from the previous setting.


1 Like

This topic was automatically closed after 28 hours. New replies are no longer allowed.

We have a project where there are a lot of main parent tasks, each containing subtasks. We very much DO NOT want the custom fields of the parent tasks showing up in the Subtasks.

We have subtasks that are automatically created to inform team members to go change a custom field in the Parent Task at certain points in time. It’s human nature to accidentally change that custom field in the subtask instead, which obviously doesn’t work.

It’s especially frustrating when you’re teaching a new person how to do this. They always get confused. The moment they see that custom field in the subtask, they change it, instead of navigating up to the parent task to change it.

Is there any way to turn this off?

Hi @Matt5,

I merged your post with an existing thread on this topic.

There is not. But you shouldn’t see those fields without having to click “Show inherited fields”, right? That was Asana’s partial solution to this behavior…

Phil, they show up on Mobile by default. At least on a Samsung S22 Ultra and a Samsung Tablet. Which, is the worst possible place for them to show up, because they junk up the screen with options that aren’t needed for a subtask lol.

Also, it really kills us, because our mobile app users tend to also be our LEAST savvy when it comes to software, because usually these users are hands-on mechanics who are far more comfortable with torque wrenches and micrometers than they are with software.

1 Like

Ah, yes, mobile! :slightly_frowning_face: :slightly_frowning_face:

If I were you, I think I would create a new Product Feedback thread here specifically relating to mobile with the ask to hide them there by default or something like that.

Not only that, but mobile is where there’s the least amount of screen real estate so if anything, mobile should lean toward showing less data rather than more.


Created dedicated topic to hide inherited custom fields on mobile

1 Like