Why keep orphaned tasks when deleting a project?

I read that tasks assigned to people are NOT deleted when the project is deleted. I’m not sure why that’s useful? Most of our projects come from templates, with pre-assigned tasks, so when we delete them we want all those tasks to disappear too. But they don’t - they stay in the assigned person’s list but without any clue which project it was. They are effectively useless at that point. There’s no mention of the original project visible.

Worse, I have no idea who to contact to help them fix this. Can we have an option popup to delete tasks when deleting a project?

Some users create tasks that make a lot of sense even when freestanding - not needing project context. The project assignment(s) may not have been a meaningful association(s) in the first place…in Asana you must assign a task to a project simply to be able to view it from a project. In this scenario, for project deletion to also cause deletion of tasks that may have been assigned to it would not be desirable.

If I were you, I’d use the workaround of bulk unassigning (50 at a time) tasks before deleting a project.

1 Like

Hi @James_Shaw and welcome to the Forum! :wave:

That is correct. At the moment, Tasks assigned or multihomed in other Projects won’t be deleted. You can learn more about it in the following article: Setting Up a Project in Asana | Product Guide • Asana Product Guide

As @Stephanie_Oberg mentioned, what you could do is multiselect these task and delete them before deleting the Project.

I hope this helps! Have a great day! :grinning:

1 Like

I agree with you James - this configuration doesn’t make much sense to me.

3 Likes

I want to revisit this topic to really understand what is the best practice around removing projects. As @James_Shaw mentioned, many projects are created from templates (or imports) and are pre-assigned. Given such, if there is an error with how a project is created or the overall use of such is being abandoned… the expectation might often be to delete all layers associated with this project.

I want to point out that I see @Stephanie_Oberg’s point and definitely agree that freestanding tasks can and often have a lot of value thus not requiring a project relationship. That said, I think the focus here is how to properly “undue” something as a whole when no longer needed. The first step in this process as a best practice, might be exactly what @Stephanie_Oberg suggests by performing a bulk assignment.

Regarding this bulk assignment, I want to understand what happens to subtasks in this scenario. If I were to perform a bulk assignment, this would only apply to parent or level-one subtasks. Would it be better to instead perform an Advanced Search across the project which would show ALL LAYERS of tasks (meaning those subtasks that might be 5 levels deep) before attempting to bulk unassign? At this point, would it be safe to delete the Project knowing there are no assigned tasks at any level?

Historically, I was under the impression that in order to prevent any orphan subtasks, I would need to first delete all parent tasks, prior to deleting a project. I’m not confident that this practice produced the results that I would expect. Can someone confirm that this will also delete subtasks (however many levels deep) associated with this parent task regardless of whether they are assigned? If the behavior matches that of a Project deletion and the subtasks where there are assignments will be retained, perhaps this goes back to the bulk unassignment being the best first step.

Here are two scenarios that I described above. Looking to confirm this behavior and then come to terms on what the best steps are to take when someone wants to undue tasks/subtasks placed on a project:

Scenario Hierarchy
Task (unassigned)
— Subtask (unassigned)
------ Subtask of a Subtask (assigned to me)
--------- Subtask of a Subtask of a Subtask (unassigned)
------------ Subtask of a Subtask of a Subtask of a Subtask (assigned to me)

Scenario 1 - Project Deletion - Because The Task and Subtask are unassigned they will be deleted. “Subtask of a Subtask” and “Subtask of a Subtask of a Subtask of a Subtask” will remain and be assigned to me. Will “Subtask of a Subtask of a Subtask” still exist even though it is unassigned? Will the association between “Subtask of a Subtask” and “Subtask of a Subtask of a Subtask of a Subtask” be broken if the task in-between is deleted?

Scenario 2 - Parent Task Deletion - When deleting a task or subtask, all layers beneath the layer being removed will be deleted REGARDLESS if they are assigned or multi-homed. Is this correct? If this is correct then perhaps the bulk unassign from the Project view (rather than performing an Advanced Search) is all that is necessary.

Sorry for the long post. Hope this makes sense. If it doesn’t please engage in the conversation. I’m very interested to understand this behavior and assume others are as well!

For what it is worth. I ran a test for the scenarios above and the results were as follows… even more confused now…

Scenario 1 - Delete the Project - Results

  1. Project is deleted
  2. Project ID is different when viewing the task/subtask links - new ID = 1475511953523 (appears to lead to my tasks)
  3. All tasks and subtasks show to be deleted but not permanently (yet)
  4. All task and subtask hierarchy is lost

Scenario 2 - Delete the Parent Task - Results

  1. Project remains
  2. Task and Subtask retain the original project ID of 1181529766877872
  3. All other subtasks have the new Project ID of 1475511953523 (appears to lead to my tasks)
  4. All tasks and subtasks show to be deleted but not permanently (yet)
  5. All task and subtask hierarchy is lost

For what it is worth, I got some clear direction from one of the Product Managers on what happens in situations where a Project or Task needs is deleted.

When deleting a project, tasks that meet one of these conditions remain:

  1. Tasks that are assigned
  2. Tasks that are multihomed to another project
  3. Subtasks where the parent task remains (not deleted)
  4. Subtasks that are multi-homed to another project (those that are assigned will be deleted, if not multi-homed or having a parent task that remains)

==== Here are some scenarios to better paint that picture…

Subtasks are only deleted if the parent task is deleted. The only exception being when a subtask is multi-homed. The parent task is whichever task the subtask is tied to, even if this parent task is actually another subtask. They operate as little independent systems. So something like:

  • Project ← deleted by user
  • Task 1 ← deleted because neither assigned nor multi-homed
  • Sub-task 1 (assigned) ← deleted because it’s not multi-homed
  • Sub-sub-task 1 (multi-homed) ← not deleted because multi-homed
  • Sub-sub-sub-task 1 ← not deleted because parent task was not deleted

When deleting a task, all layers below will be deleted unless they are multi-homed to a separate project, then affect below layers. See example:

  • Task 1 ← deleted
  • Sub-task 1 (assigned) ← deleted because it’s not multi-homed
  • Sub-sub-task 1 (multi-homed) ← not deleted because multi-homed
  • Sub-sub-sub-task 1 ← not deleted because parent task above was not deleted

If you want everything deleted and gone, ensure everything is unassigned and/or not multi-homed.

Thanks. I think we knew most of that, but this is more detailed, so thanks.

The problem remains that the tasks left behind, say because they are assigned to someone, are next to useless (to us anyway) because the project has gone.

We have many templates, and they all have this issue, but let me give you one example.

Let’s say “Onboarding a new hire” is a template. We create a project, that has 200 tasks in it. They are all assigned to people, so whenever we hire someone, 200 tasks get assigned to people. It’s awesome!

The name of the project is the key to this. Having a task “do something” is literally useless when the project name has gone (The project name would be “Onboard John Smith”). Without the project name the task isn’t actionable at all.

I just wish someone would listen to this thread, and give us a simple prompt “delete all tasks?” or similar, when we delete a project. All this assigned, multi-homed, etc seems all super well-defined, but to what end? Who benefits?

I use Asana only for this template behavior… creating a project from one of many templates and hundreds of tasks get assigned. Am I unusual in this usage?

You aren’t unusual in this usage at all @James_Shaw! I think the general practice by many Asanas would be NOT to delete projects. I would argue the majority of them aren’t creating items in bulk via templates, however. If so, they aren’t likely to be for projects creations that might been to be undone. For this reason, I think the conservative approach is taken which would be to a) not delete tasks that are assigned at the project level and b) not delete items that are multi-homed. While it does create a little bit of extra work for me (and a general understanding by many that work within our team), I can respect the approach.

I wholeheartedly agree with your stance that tasks (at any level really) don’t hold as much value without the Project reference. The way my team structures most things, the Project is the most powerful reference to the work that needs to be done. Without it, you lose a lot of clarity on the work. Because there is a mix of uses here, I think your suggestion of a “delete all tasks” is a powerful one. I haven’t come across that in the #productfeedback. You might consider adding that to the title of this post. I’m sure you would get more upvotes if something as simple as a warning, like you get for sections (see below), was offered prior to deleting a project. Of course, in this instance it would warn that all assigned or multi-homed tasks would be deleted.

I think your suggestion of a “delete all tasks” is a powerful one. I haven’t come across that in the #productfeedback.

Jerod, this looks to be the same (more specific) ask so I upvoted that one: Ability to delete a project and associated tasks?