No worries, Iām happy to develop a little on this!
Rules currently donāt work with subtasks because subtasks donāt automatically ineharate their parent task attributes (and their project more specifically). Instead of using a Task > Subtask hierachy, I was recommending to use a Section > Task hierarchy (with Section replacing the task level, and tasks acting up as subtasks). This is just a workaround to be able to leverage Rules in a workflow that involves multiple actions to complete a single task. Again, this was just a workaround to explore, not a direct solution to the problem exposed by Chris!
I hope this helps to clear things up but let me know if you have any follwo-up questions!
Hi @Chris_Labatt-Simon, itās currently not possible due to technical constraints, but definitely something weāre keeping in mind for future improvements!
This would be a nice feature to be able to automatically add subtasks to a task created in a specific project.
However this would be unecessary if it were possible to create a task from a template. This template could then have the desired āstandardā subtasks.
My perspective is in mechanical design and I have a task to design a machine. There are certain things that need to be checked before I send the machine off to manufacturing regardless of which machine it is. It would be nice if I could have this āchecklistā to be generated automatically when I start this task.
I 100% understand that some rules shouldnāt/canāt be applied to to subtasks. But at the very least, the āStatus Changed -->Complete Taskā and āCompleted taskā>Status Changedā Rule should be made available to subtasks. Minimizing the steps my team has to take make sure āall the boxes are checkedā would be incredibly helpful.
I agree with @Chris_Labatt-Simon and @Marko, this would be a very useful feature. Currently, the status of a each task within our projects is dependent on certain sub-tasks being completed. So having a rule that would update that status every time a sub-task is completed would be so helpful as we are doing that manually right now.
I donāt understand why subtasks would be designed NOT to inherit attributes of their parent task. What is the point of a sub task then?
In our case we are a design and fabrication firm that has to track a lot of projects utilizing a variety of in house resources and sub contractors. Our 100+ client(s) each have a āteamā level where we create a folder; then the project level is exactly that, a client specific project; then sections break down the scope of work (milestones, assigned actionables, all the elements of the project that are in production, estimate and purchase order tracking, etc). Task levels are the bullet points so to speak of what is in production (āFaux finish display blocksā for example). Subtasks would track multiple purchase orders, vendor costs, due dates, etc necessary to create that one line item.
The only solution Iāve come up with is creating another board that is our āproduction scheduleā where I can attach the sub task to a project. The problem is it takes to many clicks to get into the task, locate the add to a project tab (it is not offered in fields because sub tasks donāt inherit parent structure), then assign it to that tasks where I can then fill out the custom fields I need to track my project. Itās just too many clicks for a fast paced work flow like ours. What is interesting though is if you select multiple sub tasks you can batch move them to a project, so I wish Control + select on a single task or sub task would give you the same streamline option to move tasks between projects.
Our problem is that typically we are generating POās one at a time so need a better work flow in getting items onto the production schedule to make sure they are accounted for and billed at the end of a job. Was hoping rules would help solve that by automatically adding these sub tasks to the production schedule but alasā¦it will not.
Long story short Iāve been using Asana for about 3 years and have always found it to be very frustrating that sub tasks donāt inherit parent tasks attributes. Can someone please explain why? The work arounds never really seem to workā¦but if someone has had similar experience and an effective solution Iām all ears.
The basic design of Asana is that tasks assigned to a project appear in that projectās task list. Given this model, when a subtask is assigned to a project, it displays in the projectās task list. I donāt know this for a fact but I strongly suspect that the Asana folks concluded that automatically assigning all subtasks to their parent taskās project, thereby causing them all to appear in the projectās task list, would be too unwieldy and would be counterproductive.
I think the only solution would be for them to alter the basic design of Asana such that subtasks assigned to a project would not show in the projectās task list. Again I donāt know this but I suspect that given Asanaās architecture, it would be a heavy lift for them to make make that change. (Although interestingly itās the design Iām implementing for my upcoming Desksana integration.)
You might be able to solve this using the "Add subtasks from a template" rule action in Flowsana. What Iām thinking is to assign the subtasks in the template to the āProduction Scheduleā project so that when theyāre duplicated, theyāll be assigned to that project when theyāre created. I donāt know if that matches your workflow without knowing more about it, but it might. The other issue is that the templated subtasks will show in that project, which you donāt really want, but perhaps since they wonāt have any start or due dates on them, that wouldnāt be an unbearable issue.
I agree with @Chris_Labatt-Simon as well. It would create efficiencies for our organization, which currently not having that ability means it is something we have to do manually.
For me subtasks are steps of a given task, whatever its environment. This is the result of you splitting the work of a task assigned to you. It is often a private split of a publicly assigned work.
I would also like to be able to use rules triggered by subtasks. For example, I would like to have a task (with multiple tasks) moved in a new section when a certain (key) subtask is completed. Apparently i cannot do that at the moment, but it would be great if I could.
Jira also has a better implementation of the EPIC concept - essentially letting you nest tasks in tasks in tasks, creating the āsubtaskā effect, but maintaining all the functionality of a task. That would be a great addition to Asana. Now, the only way to really create the EPIC concept, you have to create a separate project and then assign tasks to multiple projects to keep track, but also to allow that epic ābucketā with potentially dozens of tasks that make it up, and will be delivered over weeks or months.
Because we integrate with Screenful to track sprints, we create a singular project for all sprints within a timeframe (an epic if you will). The project is set up in board view to represent a Kanban board. Each task is a user story in the sprint, and each user story has subtasks that represent the work to be done to meet the story. Our use case for rules here would be to trigger moving the user story to a new section of the board when all of its subtasks are marked done.
As a quick follow up to my post - one way to make this work is to make the āparentā task be dependent on all itās subtasks. You can then write a rule using the āNo longer waitingā trigger and take some action. The danger is that the rule would fire for any task in the project that gets a dependency. So some manual governance would be required to make it work.
The solution to change the list view to Section->Task instead of Task->Subtask is good until your project is big enough that it need to be split in sections. Maybe, having subsection could resolve this issue (Section->Subsection->Task)?
There is a dedicated thread about sub-sections if you want to upvote Also if a project becomes too big you can also consider having several projects in some cases.
Also if a project becomes too big you can also consider having several projects in some cases.