I have an issue when doing a CSV import of tasks with dependencies. The dependencies, when they exist, are coming through correctly, but tasks for which that column is blank (they are NOT dependent on any other task) are coming through in Asana as “Dependent on (unnamed task)”. I am having to manually go through all the non-dependent tasks once the project is imported in Asana and manually undo these dependencies.
How can I avoid this so that I can import a project where some tasks have dependencies and others do not?
The dependent task should be located above the current row in the CSV file and they should correspond to the dependent task names exactly. It’ll be very helpful if you can send me a screenshot of how you are organizing your CSV file.
If you don’t feel comfortable sharing the screenshot publicly in the this thread, feel free to DM me (You just need to click on my name above and select “Message”).
@Emily_Roman one thing I have always struggled with is that dependent tasks should be located above the current row in the CSV. I understand this is so that the current row “knows” which task is dependent of the current row. If you think of this from the perspective of a parent task being dependent on the completion of its subtasks, you run into a conflict because in order to list a subtask the parent task has to already be known. Yet you can’t list the parent task before the subtasks if it is dependent on the subtasks.
If you get away from the dependency relationships between parent tasks and subtasks, I’ve always felt that items should be listed in the order the actions need to be completed (top being more recently due than those at the bottom). You can’t achieve this if the dependent tasks have to be listed before the current row.
This is interesting because when working within Asana live you map the dependency in the opposite way! You literally edit a task to “make dependent” on a task that already exists. With the import, you are stating where tasks are depending on the current row. Any chance that the import process could flow like Asana does in its live state? I know nothing about programming but I assume this would only be achievable if dependency mapping was performed across an import of tasks as a final step rather than expecting all the known data to be available upon importing each row of data in full.
@Phil_Seeman, does what I am saying make sense to you?
@LEGGO, I think you’ve done way more with CSV imports than I have. One thing I’d like - especially given the inconsistency in the docs that I pointed out in another thread yesterday - is definitive answers to two questions; maybe you can provide this:
Do subtasks need to go above or below their parent task in the import file?
Do dependent tasks need to go above or below their antecedent task in the import file?
It seems there is some confusion about these questions on the forum - or maybe the confusion is just in my head!
BELOW. For Subtask mapping to occur via import, the Parent task to associate with the subtask needs to be defined first (above on the list). I have not issues with this ordering.
ABOVE. Dependent tasks need to be listed before the tasks they are dependent upon via import. This is opposite of how it works in the web - there the tasks that need to be completed first have to be created in order to “make dependent” the dependent task. This is the ordering I have issues with because when importing the “things to do first” need to be listed AFTER those that dependent on said tasks.
I guess I wouldn’t have as much of an issue with the order of dependencies IF there was a way to set the order of tasks - how they get listed top to bottom when the import is complete!
Beautiful - thanks for providing definitive answers - and for confirming the inconsistency between those two!
I agree that the ABOVE requirement on dependent tasks is (a) inconsistent with subtasks and (b) causes the issue you describe in your other post further above.
I’d recommend you turn that post into a new thread in the Product Feedback section so we can lobby for a change in the importer requirement re. dependent tasks.
Hi Emily, I figured out what was going on in my case.
Our company organizes our Asana projects with “Top Priorities” that each have various “Goals” underneath them, with tasks for each goal. So we always have a Top Priority header (section) with no tasks in it. This is what it looks like in Asana (image 1):
In my spreadsheet, I was leaving a blank task row to create that Top Priority section (and then I manually delete the task that is created once the upload to Asana is complete). So the tasks that I did not set a dependency for were linking as dependent on this unnamed task. My original spreadsheet thus looked like image 2 above.
I fixed the problem by simply naming the task I’ll delete as “delete”, and then non-dependent tasks stopped being marked as dependent. (Change marked in green in image 3 above)
Is there any way to create a Section with no tasks in it via csv import? (i.e. any way around having to manually delete the unnamed tasks as I’m currently doing)
Hi @Caroline_Davidson, thanks for confirming this information! I see what you mean!
Unfortunately it’s currently not possible to create an empty section via the CSV importer. The section should be at least associated to one task. I had a look internally and I see this is something our product team is aware of and it’ll be considered in future updates for the CSV importer. In the meantime, as a workaround you can create an advanced search report of the task under the “delete” title and delete them all using the multi-select feature.
I also recommend you creating a request for the option to import empty sections via CSV in our #productfeedback category so other users can upvote for this feature as well!
I hope this helps! Let me know if you have any other questions!
Hi @LEGGO, thanks for reaching out and sorry for the late follow up here! I see you created a product feedback thread for this. I’ll have a look and reply to you in the main thread. I hope you don’t mind!
that the ABOVE requirement on dependent tasks is (a) inconsistent with subtasks and (b) causes the issue you describe in your other post further above.