Make Custom Fields on subtasks optional

I totally understand the need for this to be optional for everyone. For our process, which we have altered to fit into this world of subtasks not inheriting its parent’s custom fields by…

  1. Promoting subtasks to the project, which clutters the project with tasks not everyone needs to see.
  2. I had to create a template system that included a primary deliverable and all of its subtasks in the project, with a date of say 2030. Then I duplicate the deliverable, which creates no due date copies. Then I select the copies and add them to the proper project.

We have custom fields that indicate what client service we are billing to… Each client may have multiple services, so this provides a way for us to charge that service specifically, as well as report on what we do for each service. This is done through 2 custom fields that provide reporting data to Everhour (time tracking). But the only way to get these fields on the subtasks is to add the subtasks to the project. Doing this manually is ridiculous. I had a system that would add the subtasks to the project, add the fields, then remove them from the project, but that was way too complicated and cumbersome.

So we have a very big need for subtasks to inherit the parent tasks’s custom fields.

I don’t care if it’s an ON/OFF preference, or a switch on the parent task to “send to all subtasks” or on the subtask to "receive all parent task custom fields. Actually, thinking about the 3rd one, that would be hard to do in practice, as I would have to navigate to each task, so that wouldn’t be a good option. If at some point Asana moves to a way where the primary task list shifts levels, so for example, if I wanted to see the subtask level, then all the subtasks would be in the task list, thus I could affect multiple subtasks at once without having to navigate individually to each one. Hopefully that makes sense.

Totally understand that there are use cases where inheriting the custom fields in subtasks makes sense, but I would argue that there are way more use cases where it totally doesn’t make sense. Totally agree with Richard_Uruchurtu - this cheapens the entire platform :-(.

7 Likes

This change is driving me nuts as well! I like the mockup to make a custom field show up on a subtask or not. Right now, we’re so confused people can’t remember which field to complete and which not to complete and so they’re just not getting filled out. Bad! Please prioritize a fix.

2 Likes

@Marie we lack your respons, this is critical for many of us. Please, give us an update, the silence is too long without respons from Asana.

7 Likes

Totally agree! Please can we have some sort of update @Marie

3 Likes

In the same boat here. It is not a bad idea for the fields to be available however, if you have built processes it completly messes them up. Hopefully there is an update soon on how they are going to deal with this.

4 Likes

Hey @Marie now we have been quickly gaining votes here and we will probably pass that “very popular” request soon. We collected 80 in 3 weeks and that popular post did it in four years. Mostly because users there didn’t know how to use asana. The people raising their voice here also seems to be the persons overlooking and structuring asana for their whole organizations. I guess you understand that you have some ambassadors in each organization? And the persons commenting here seems like they are the ones in their orgs. So this is just the tip of the iceberg of affected users that have a problem with this change. And we are the ones in our organizations that really have pushed for asana(so you can imagine how the non supporters sound like) . So a response would be nice. Do you have any plans to adress this issue at all? Or are you just ignoring that this caused an issue for us? :blush:

5 Likes

Hi @JFrentz, @Jonas_O,

First of all, thanks to everyone who took the time to share their feedback and upvote this thread, we really appreciate your feedback. I’m closely monitoring this thread and shared it with our team pretty much as soon as it was created. While we don’t have immediate plans to project make custom fields optional on subtasks, this is definitely something we will take on board for future updates. I will be sure to keep you posted here as soon as I have some updates from my end, but in the meantime, I would encourage anyone running into issues with custom fields to upvote this thread and to share some context (why is this breaking your workflow or generating some confusion); this will be very helpful to help me report to the team and inform our next update.

Sorry, not enough to put it in the backlog! People see stuff they shouldn’t see and we have no way to control it? You have made a major change in the core view, it’s not even logic to push data fields to child, show me the inspirational case of where this is useful, please. What other data storage interface does it? What is the use case you are solving?

The screenshot is just one example that I got from one of the organization yesterday. Increase the priority. You have made major changes in all subtask views without benefit. The team is wondering what to do with these input fields, they are of no use and we can’t control it.

Why do i see these what should i do with them

4 Likes

Hi @Marie ,
I am still finding it difficult to understand that Asana is not seeing the gravity of their mistake here.
My process participants are filling in fields at the wrong levels now and the confusion is huge. Pretty much all the tasks in our processes are showing multiple fields that shouldn’t be there. It is a huge mess and I am already considering a move to another platform to be honest, because this is unworkable.
I’m getting the impression you guys in Asana don’t even know how great and versatile your platform was before you ruined it with this update that, let’s be honest, adds very little value really.

Please revert this or at least prioritise this fix.

3 Likes

image

We use Asana much like Salesforce is built (moved form SalesForce to Asana, built reporting with your API.

Now we have contact persons with invoicing address from our customer, we have projects with contract information and invoicing units with project milestone.

THIS COMPLETELY ANNIHILATES OUR WORKFLOWS - REVERT THE CHANGE ASAP!!!

6 Likes

I still haven’t seen a convincing case for why you would want duplicated custom fields on sub-tasks in the first place, but here’s an example of why this is causing issues:

One of our projects is used to manage our content queue. The main task is the actual article, and the custom fields are things like word count, primary keyword, and current stage (there are about 10-15 of these). Sub-tasks are things like keyword research, write first draft, upload article etc.

With this latest change, each sub-task now has a long list of empty custom fields that are irrelevant to the task that staff need to scroll through just to get to the actual task information, which is contained in their own set of sub-tasks. Information is also now getting filled in at the sub-task level rather than the primary task by mistake, which confuses things further.

5 Likes

As everyone here stated, it is a great nuisance. Perhaps a handful of people that created the fields would be able to manage with the unnecessary fields but a vast majority are simply overwhelmed by them and create confusion on all fronts.

My team would greatly appreciate if this is removed or at least make this optional.

4 Likes

We use Asana to manage our translation and localization workflow.
We have a template task with all subtasks already set up, that maps out all the steps that happen along the translation process flow. We are using dependencies between tasks to make the process as seamless as possible. The parent task is owned by our main translation vendor and the next layer of subtasks is owned by the relevant owners of their process steps. The layer below those are owned by the individual linguists who complete actual translation and linguistic quality assurance work for us. We even use Asana custom fields to collect information like language quality ratings and the time linguists spend on tasks for billing purposes. We have a lot of custom fields connected to our database via API.
Most of the participants are part of vendor companies outside of our organisation.
Each “layer” has specific custom fields that were set up for the owners of those tasks. I depend on process participants to fill in the fields correctly, in the correct task, for our billing and reporting to work correctly.
Now fields are filled in regularly at the wrong level, where people get confused and overwhelmed by the extreme number of custom fields.
I tried to rename the fields in a way that everybody knows which fields are meant for them (I had to get help from Dev as those name changes affected our API!), but this doesn’t solve the problem as the higher-level owners, such as project managers on the vendor side, have access to the lower-level tasks as well, and they regularly fill in the custom fields in the wrong place.
Here is a screenshot of what our view now looks like. It is horrendous.
The item highlighted in yellow is the only custom field relevant for this task. Everything else is inherited from the layer above and makes zero sense here.

3 Likes

@Marie Can you point me to or ask your product management team for best practice documentation on how to use this new feature? My team and I are really struggling to understand the benefits of this update and how this change does not make all subtasks and/or fields unusable.

Our processes are broken as there are too many unnecessary fields on subtasks. Please help us understand how we should use subtasks according to Asana best practices so that we can re-design our processes. (e.g., should we just use highly generalized fields? e.g., Status, Urgency, business unit and use “tags” for detailed info about the task?) We need more concrete guidance.

Asana has completely changed how tasks-subtasks are to be used and leveraged in Asana’s system and there seems to be no best practice documentation or guidance regarding how/when to use subtasks or fields. When I go to the Forums all I see are upset clients about this. I do not see anyone posting use cases where this solves for X problem or users providing workaround or ideas on managing tasks/subtasks. I think everyone here is very capable in Asana and needs guidance on this new feature.

Please help me find someone who can tell me how having these fields in subtasks will make using Asana easier and I can build around that. Otherwise please help explain what is going on and the thinking around this release. Without this context, it brings up concern as it looks like your product management team does not know how your users use your product.

Thank you for your help.

5 Likes

I couldn’t agree more. I would add that it looks like they don’t know how great and versatile Asana is :slight_smile:

2 Likes

I do agree that this feature should be optional for all of the reasons folks have raised on this thread, but I would like to provide some context around how the feature is important for some.

Our team finds custom fields on sub-tasks to be extremely useful, particularly when it comes to tracking effort. Hours on sub-tasks do not mirror the parent task because each sub-task takes a different amount of time. Some sub-tasks are also allocated differently (tracked via sub-tasks) depending on who is doing the work. Also, since sub-tasks are sometimes performed by different people, roll-ups to the parent level don’t make sense. Hope this help clarify a bit.

2 Likes

Thank you for clarification @Joe_Moran. :raised_hands:
I appreciate that you highlight issues that would possibly occur if bleeding custom fields also was mirrored. I believe many of us have the same use case. Some custom fields are useful on subtasks as well, In your case, it’s about a time estimate. :+1:

We have solved this in two ways which I believe is not well understood in the community by reading the requests and use-cases described in the source thread that caused this in the first place.

  1. The task and their subtask should all belong to the same project where they inherit the custom field because in some way it’s the same task type or at least they need the same qualities. In this case, both the main tasks their subtasks could belong to the project named “Estimates” or “Billable” or something like that.
  2. If they both already belong to two different projects defining their individual type, like project “Main tasks” and “Actions task”, both could have the estimates custom fields and achieve the same result.

This has been possible to achieve as long as I can remember since we got custom fields.
It requires minimal additional structure and administration, but if that is an issue, let me know because we live with automation inside Asana, which I strongly believe is our shared future. So that additional friction administration will evaporate and it’s already worth the additional structure.

The graph qualities in Asana are very powerful. :slight_smile:

1 Like

Thanks, @JFrentz! Our goal is actually to manage all tasks in one project. These workarounds are driving us mad. We’re using custom fields to track necessary allocations for our PMO.

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.

2 Likes