Back to the guides

PRACTICAL SOFTWARE GUIDE

Asana CSV imports: reconcile parents, dependencies and repeated uploads

For teams whose spreadsheet becomes tasks but loses the intended work structure.

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Define the work graph before uploading

Asana's advanced CSV guide describes parent-task matching using the Parent Task column and exact task names, with parents appearing above their subtasks. It warns that duplicate names can match the closest preceding row. CSV import creates tasks rather than updating existing project tasks, so repeating a file is not a general update mechanism. Inspect the intended parent and dependency structure before completing the import.

Our recommendation is a migration worksheet containing source references, expected task count and expected relationships. Rows and project cards alone do not prove that the work structure survived.

A fictional exhibition pilot

Assume an exhibition project contains a parent task called Prepare exhibition package and three child items: confirm artwork list, prepare transport brief and approve labels. Another task, publish visitor guide, depends on the approved material. Use distinctive synthetic names and write the expected parent-child and predecessor relationships before importing.

The sample is a proposed acceptance dataset, not an Asana template or a measured migration result. Avoid repeating a generic parent name such as Review when the importer must resolve the relationship by name.

Prepare and inspect

  1. Retain the original source and assign a stable reference to every intended item.
  2. Give imported tasks unambiguous names.
  3. Place each parent before its children and review the Parent Task mappings.
  4. Follow the current documented dependency-column convention and verify direction on a small sample.
  5. Inspect field mappings, dates, assignees and character encoding in preview.
  6. Import only the pilot and reconcile task identities and relationships.

Count relationships as well as tasks

Our acceptance rule is not merely five visible items. The three intended children must belong to the right parent, and the publication work must reference the correct prerequisite. Open representative details and inspect the resulting structure rather than inferring it from row order in a list view.

Include one intentionally ambiguous name and one invalid option in an isolated rehearsal. Document which cases need correction and which should be excluded from the production file.

Keep repeat imports deliberate

If one imported item is wrong, identify that item and the supported repair method before uploading the whole file again. The official guide's create-not-update limitation makes blind repetition an unsafe assumption.

Also distinguish task fields from project-wide schema. Custom fields created during import can be local to the project, so a successful file mapping does not automatically establish a shared organization-wide reporting definition.

Launch gate

Proceed when expected source references reconcile to destination tasks, the correct parent and dependency relationships are visible and a colleague can explain every exception. Keep import recovery separate from downstream actions or notifications that may already have happened.

This article provides a source-based pilot and reconciliation procedure. It does not claim a completed Asana import test, a file-size allowance or automatic reversibility of external side effects. Consult current account controls and import documentation for the exact supported fields.

Sources and verification

Official documentation checked on 2026-10-29. Worked examples are hypothetical planning exercises, not measured product benchmarks.

Continue your evaluation