Workflow Design Fundamentals
Start from the outcome, not the tool
Workflow design begins by naming the deliverable, the stages it passes through, and who owns each stage. Asana expresses this with projects (a container of work), sections (columns representing stages or categories), tasks (units of work), and subtasks (breakdowns inside a task). A workflow is sound when every task has one clear home, one owner, and a defined definition of done.
Core concepts to know
Understand the difference between a stage-based board (To Do → In Progress → Review → Done) and a category-based list (by client, team, or work type). Know that a task lives in exactly one section of a project at a time, so sections model state transitions cleanly. Understand multi-homing: one task can belong to several projects at once, which is powerful for cross-team visibility but risky when different projects carry conflicting sections or fields. Recognize the role of task completion as the terminal state and that completed tasks leave the default view.
Traps in questions
Watch for options that add custom fields to model stages when sections already do it, or that create duplicate projects per stage instead of sections within one project. Another common trap: assuming subtasks inherit the parent's project membership for reporting - they do not appear in the parent project's list by default.
Rule of thumb
If a piece of information describes where work is in a process, use a section. If it describes an attribute of the work (priority, cost, region), use a custom field. If it describes a separate deliverable, use a task or subtask.