Make Custom Fields on subtasks optional

That solution would be acceptable for our organization too.

3 Likes

I agree!

I trust in the need to access childs through the list, without closing the list-view with details.

The scrolling issue(unnecessary precious space) described by @Jess_K is a fact.

This doesn’t seem to fit our expected route of Asana calmness. Adding extra empty duplicated fields for all users on all views? Nah, Asana is minimalistic and on point, this is not :person_in_lotus_position:.

As a user, designer of Asana based organizations, I need to be able to define what fields are relevant or not on subtasks. Every Asana user should design their Asana experience, in some way, keep it nice and tightly ordered together, headspace, right? So far this feature is not :person_in_lotus_position:.

You are forcing a new release which adds unnecessary friction on all subtasks, for all users. It’s not a good experience. The required efforts for the users is not balanced. Can there be a simpler solution? This doesn’t feel ready yet. :blush:

I would love to see the use cases to support the rollout, as is.

If the options would be to:

A. Rollback :roller_coaster:
B. Add option to show or disable custom fields on subtask
C. Add option to disable subtask custom field from parent, in custom fields settings.
D. Add sync in the hierarchy so that the -custom field is the same on all tasks. :rofl: .
E… Add sync in the hierarchy so that the values would be the same for all -custom fields based on the visualization settings for that specific custom field in the project.

If the list view are a parent view of the group of tasks that belongs to them, then it would make more senes to leave those cells blank as you have designed for, but not by showing them empty on task as well. Only fields that should be passed down would possibly have values in the list view and even show on the task view. It’s simpler for the viewer and would lower the messiness described by @Jess_K.

  1. So that would leave out option A and B. :point_up:
  2. Option C would be too detailed, this comes from parent, project and custom field, not from the Task, this would be a lot of effort to configure individual tasks.
  3. Adding sync to the hierarchy would add a benefit even for us, because then the id, first name, registration number of the car, or what else we would like to show in a subtask would be the same as the parent when updated by assigned subtask, it would automatically be updated in parent task, as they heritage the custom field through parent and their related projects.
  4. So if the custom field values in the hierarchy would be best if synced, it should still be optional to define, if it’s relevant to be displayed on subtasks, based on the unnecessary scroll issue described above. That leaves us with option E.

This will add visual and interactive friction to all our users until it’s been resolved. Just for us, it’s affecting our customers over multiple industries and highly scalable automated organizations that have been devoted to Asana for years. This feature needs some final touches before its :person_in_lotus_position:

:unicorn: :dolphin: :heart: :person_in_lotus_position:

5 Likes

Thanks for your response @Phil_Seeman and all the work that you put into this.

  1. I suggest that it’s still visible in the list view, but not in the subtask view.
  2. If there for some design guidelines would limit us to define a UI limitation to field input, some type of validation, then so be it, but don’t display it in the subtask view, if it should not be visual there.
  3. See my full design reasoning in my previous comment.

I’m not a requester of this feature but It’s our strategy to follow Asanas path, so I trust in the possibilities with an updated list-view, where we can access subtasks, without closing list details view. If you say so, we are ready to adopt. :+1:

But to force the need for list-view and let it interfere primary experience of all subtask are not aligned with a minimal design approach, the sacrifice is not balanced.

It’s not a nice experience, for basically the first time since I dedicated myself to Asana 5 - 6 years ago. I never complain, about features, I’m on the journey and adopt but this doesnät add up.

Add the option to display parent custom fields on subtask view asap, please. Thanks! :raised_hands:

4 Likes

Wouldn’t this possible become or even be a security and privacy issue for us? We cant show all our parent customer information to the assignees of subtasks, where is the restrictions? Please, its not ready, remove it from our organisations!

3 Likes

If you just add something like below, I believe that your existing customer that has been using Asana for years would still be happy, and the people that requested this update would be happy too. They would in theory still be able to edit the fields from the Listview, but then having the option to see the fields on the subtask or not.

13 Likes

So I was planning to contact Asana to tell them we had a HUGE bug with our organization when I discovered with this topic that it is in reality a new “feature” ??? How can you team drop a bomb like this without notice @Marie ? Overnight the organization we spent months to build and implement has just became a complete mess…

Your whole solution is based on projects : each project is a dedicated space with his own features (members, custom fields, presentation, …) and tasks/subtasks are just supposed to be put in the right projects depending on your needs. This solution has its limitations but at least it is a good way to keep your organization clean an tidy : tasks only carries the information you want them to carry.

But now with this feature subtasks are drilling holes in the “walls” between projects. If I wanted a subtask to have the same fields as its parent I would have simply put it in the same project, or added those fields to the project were the subtask is ! Now my subtasks all carry useless fields which are meaningful ONLY for their parents. People in my organization are now lost as they are flooded with fields they don’t know/don’t need to use…

I understood the explanation given by @Phil_Seeman but I think the benefits of this update are by far outweighed by the disavantages, and I don’t understand how those were not anticipated. The only explanation I have is that maybe you have a bigger plan and you want to implement a solution like the one @JFrentz presented ? If that the case I can only support it as I already developed a custom application to synchronise tasks and subtasks custom fields across our organization and it is a major plus for our Asana experience. Having it native in Asana would be a blast, but if that is your plan please wait to release the full feature instead of releasing only the first step …

I’m a big supporter of Asana and a very enthusiastic user, but this time I am clearly disappointed by how this feature was handled :cry:

12 Likes

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