Make Custom Fields on subtasks optional

I have already commented on the product update post but want to add my voice to the growing number here. This feature is not at all ready to be rolled out, like many of the other posters here, this “feature” has destroyed my workflow and flushed the my UX down the toilet! Please roll this back or make it optional ASAP.

8 Likes

You have missed tons of Asana use cases here! This is causing huge issues for many users. You need to revert this until you have sorted out a solution for this. Huge boo boo on your side!

My suggestion:
Add a checkbox in the custom field settings “Subtask inherits custom field”. If this is NOT ticked, everything stays as it was.

6 Likes

So you call it a “side effect of the update”, so you’re basically agreeing that it’s a bug! Please roll back until you have a solution for this.

On another note: Inheriting the custom fields from the parent task would only make sense if the values are also inherited. If that was the case I could kind of live with the feature, but would still prefer it to be configurable. Inheriting the fields without the values makes zero sense and is clearly a bug.

2 Likes

@Julia_Cassidy1 @JFrentz @Jonas_O,

Uh-oh I think there may be some misconception - just to be clear, I’m not an Asana employee, just a user and 3rd party developer - I don’t have any sway over Asana’s decisions on this (or any) software change. I’m just expressing my take on things here in the forum.

3 Likes

Nope, not at all a bug! “Bug” doesn’t follow from “side effect”, apologies if my wording is misleading.

A “bug” is a behavior of software that’s different from how it was designed or intended to work. In this case, the current behavior (including all of a project’s custom fields in a subtask’s detail pane) is exactly how the Asana folks designed and intended it to work. I totally get that it doesn’t work for you and some others here - no argument with that - but just to be precise, it’s not a bug.

2 Likes

This is a terrible update. It just adds confusion to sub-tasks, increasing clutter (every one of our sub-tasks now has 8 useless fields on it), and I can’t believe this wasn’t tested before it rolled out to everyone.

The worst part for our team is that the new show sub-tasks in list view feature, which started this mess, ruins the sum feature, because it can’t calculate a total for more than tasks with more than 30 sub-tasks. I’m just trying to plan sprint capacity and the ‘sum’ feature is really not that hard to get right. Features like this need to be implemented with far more care.

6 Likes

So I went and had a little look through the ‘popular request’ that triggered this change and wow did Asana’s team completely fail to comprehend what people were asking for!

We avoid developing further subtasks. Using custom fields (especially numerical fields) seem to be important for us in subtasks as we track time and cost.

it would be nice to have the option to further sort and categories subtasks with custom fields

I desperately need CUSTOM FIELDS for SUBTASKS.

Nowhere in any of these example requests does it say ‘I need the exact same custom fields as on my tasks to also appear on my subtasks’.

Folks, there is a huge difference between giving users the ability to put any custom fields on subtasks, of the user’s design and choice, and just forcing the same custom fields into subtasks as appear on the parent tasks. You haven’t actually succeeded in solving the original request, only a version of the request raised by a subset of the users in that thread.

To give a real use case from my own organisation: we have a project to track all jobs currently in production. Custom fields on this task include things such as billing status, whether contracts have been signed, whether invoices have been paid, etc.
Within those jobs are a series of subtasks that we treat as ‘to-dos’ - paperwork, risk assessments, budget reconciliation, and so forth. Some of those subtasks have their own custom fields, which have been set up using the project workaround - for example, the ‘safety’ subtask has 3 custom fields - assessed risk level, whether safety measures are satisfactory, and whether the job has incurred a high risk levy.

This set up works perfectly for our organisation. The internal safety officer can input risk assessment comments and update the custom fields on the safety subtask, and when they mark the subtask complete, it marks complete for the producer in the current production jobs project.

At no point does the safety officer need to see whether a job has been billed, or contracts signed, or invoices paid. Those custom fields from the parent task are totally irrelevant to them. And thanks to this update, producers cannot simply review safety ratings at a nicely colour-coded glance, with comments and docs visible onscreen immediately underneath - now they have to read through all the custom fields and scroll down down down to get to the safety officer’s comments.

Our organisation is one case, but from comments here it seems as though there are many other cases where this ‘feature’ is pointless and or damaging to existing processes.

It all begs the question - was there any UAT done at all on this feature? With real end users? This is an embarrassingly poorly planned feature for such a large tech company.

6 Likes

I couldn’t agree more! I have been such an Asana fan and advocate, convincing more and more people in the organisation to use it. I have built a complex process with custom fields and projects being used in different layers to do very specific things, also having to bear in mind access as we are working with external vendors on this.
It worked like a treat and we had already started connecting all of this to our data reporting system via API. Now we have a huge risk as some subtasks display several custom fields that are named in the same way. Nobody knows which ones to fill in anymore and what applies to where.

Asana can do so many more things than what was considered when rolling out this update. The sad thing is that Asana seems to have annoyed its power users the most :-(.
Please please please roll this back until the inheritance of custom fields is configurable.

Asana had advised users to apply their subtasks to different projects to make custom fields display there. All people who followed this advice now have a conflict. You have to think that there are people who have set up connections to other systems and have hundreds of users in some cases. A change like this is a huge problem and I hope Asana takes this seriously. If users can’t rely on features being rolled out carefully and in a way that existing functionality continues to work, then Asana will lose many Enterprise clients over this.
I really hope this is taken seriously.

6 Likes

All of this mess was created to allow subtasks to be displayed on the list view.
This improvement is totally insignificant in comparison to the damage that was done here.
Before I had to click once on the parent task and then scroll a little on the right-hand side to see all my subtasks.
Now I still have to click once.
Plus subtasks are now associated with fields they, in most cases, have NOTHING to do with.
This is not an improvement, it is a pointless feature that devalues the entire platform - and for what, to save users a little scrolling???
This is an opportunity for Asana to show what they are made of and act decisively.
I think this should be implemented like this:

5 Likes

To create relations between lists with sub-tasks is one of the key feature we use that saves us a lot of administration. We have built our planning process around linking sub-tasks to other projects. We have master lists (like CRM) where sub-tasks are linked to different production lists (communication, design, transport etc.). I can see that adding custom fields to sub-task would be a great option, but it’s not good at all to have custom fields forced from parent tasks.

As we have designed our workspaces and workflow around the features that Asana offers it’s normally positive with new features. But it would be nice if the development process would be more transparent, so we can take future changes into account and be prepared.

As you have so many engaged users maybe you could use that resource more and be a little more collaborative with us in the implementation process.

3 Likes

Having the custom fields at the project level made sense for our organization, adding them to subtasks is going to create a high level of clutter and confusion. I think allowing subtasks to have custom fields is an improvement but we need more control over this for our organization. Multihoming the subtask into the project was a good solution that now feels cheapened.

1 Like

I don’t have this feature yet, but I know for a fact it’s one of the most requested features. Subtasks were almost considered useless because they didn’t inherit their parent task’s custom fields.

While I understand that many of you have built systems around the fact that this wasn’t part of the feature set, many of us haven’t used subtasks because of this limitation. And it’s a total crazy mess and pain to keep loading subtasks to the project. I have a current system that does that, but I can’t wait to get this update.

I have no problem with making this some kind of option to be on or off, but it’s something I have been waiting for.

I’m glad that a suporter of this change is posting, since, as I stated below, I have the strange feeling I miss something big.
Can you be more specific on the use-case that makes relevant this feature that consist in duplicating at the sub-task level the same custom fields from the main-task level ?
For our workflow this is a non-sense, but the worst is that we cannot imagine how it could help others…
I would give you an concrete example:
Let’s say we have a main task regarding the implementation of a contract and the sub-tasks for different aspects of the implementation (financial aspects, technical aspects etc).
At the main level it make sense for us to store information like :

  • Type of contract
  • Contractor
  • Value
  • Validity
  • etc
    At sub-task level we used to store other specific information like Payment status, Payment type etc.
    After this recent release, at sub-task level, you have all these custom fields duplicated from the main task level, but not in sync. It is like you should insert values for the same fields at the sub-task level.
    The question is simple: What different information for the Contractor or Value of the contract could/should anyone insert at the sub-task level ?

To conclude, we think that all of us support the idea of custom field at sub-task level (without being forced to add sub-tasks to other projects), but what we advocate here for is to be able to chose what custom fields make sense to display at what level.

If you have a different approach, please share it with us !

4 Likes

I wanted to add to the voices against this new change.

It doesn’t make sense to me why you would want to duplicate custom fields in sub-tasks. It should certainly be optional, as the current implementation is cluttering up the useful data in a sub-task with fields that’ll never be used (why would they be, when the data is in the main task?)

2 Likes

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