@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.
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:
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)
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!!!
I think this may be a simple, elegant improvement to help address the concerns some of us had with the inherited custom fields feature.
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.
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.
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.
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.
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.