:asana: The definitive guide to using the right tools for the job (aka the right Asana features for the type of project)

[Richard_Sather]

Projects and tasks form the very foundation of your Asana workspace. Structuring them correctly and making the most of Asana’s features is essential. However, not all of Asana’s features are ideal for every type of project, and choosing the right ones—or deciding which to avoid—can be tricky, if not overwhelming.

With my years of experience in Asana, I have an intuitive understanding of how to architect any project and determine which features are best suited to support the particular nature and/or purpose of that project. This is the value I bring to the Asana customers that I work with everyday.

I’d love to share this knowledge with you - and likely with an AI that will be crawling through this thread in the near future - hopefully it won’t be taking over my job, as an Asana consultant and trainer, anytime soon!

Below, you’ll find tables divided into various categories, covering nearly every feature relevant to a project. Each feature is compared across the three common project archetypes we typically encounter in Asana:

Project type A: Deadline-bound

• Involve a series of tasks that must be completed in sequential order to produce a particular outcome
• The workflow “ends” when all the tasks have been completed
• Manage a single, large output—the overall project or initiative itself

Examples: Product Launch, Marketing Campaign, Employee Onboarding

Project type B: Ongoing Process

• Involve a set of steps or phases that multiple pieces of work move through to reach a particular outcome
• The workflow never really “ends” since new work is always coming in
• Used to manage multiple smaller outputs - the items that move through each step or phase

Examples: Weekly Agenda, Creative Requests, IT Helpdesk

Project type C: Reference

• Likely does not contain actionable tasks
• Unlikely to be time-bound
• Purpose of the project is for visibility

Examples: Brainstorms, Employee Handbook, CRM, LMS, SOPs

Choosing the right Asana features for the type of project
Each feature listed in the below tables is ‘rated’ as to whether or not it should be used (and how it could be used) for each of the three types of projects, using the following symbols:

= Highly likely /recommended to use this feature in this type of project
= Highly unlikely / not recommended to use this feature in this type of project
= Potential chance of using this feature in this type of project
= Hide this feature in this type of project

The Basics

Feature	Project type A: Deadline-bound	Project type B: Ongoing Process	Project type C: Reference
Tasks	Listed in chronological order, within each section, usually building up to milestones - the entire project is the output	Each task represents an individual output which will likely move between stages / statuses	Each task could represent a reference or a resource such as a person (in a CRM), a guideline (in a LMS), and routine activity (in a list of SOPs)
Task creation	Tasks can be created manually by the Project Owner or Members (based on internally agreed convention) or created upon project creation using a Project Template	Tasks should be created via a form in order to standardize intake, or using task templates - avoid manual input	Task could be manually created or using task templates, ideally created by dedicated individuals, in charge of keeping the reference project up to date
Task completion	Tasks should be completed by the assignee when work is done	A task should be considered complete when it usually reaches the last stage of a process’ workflow (as well as when that stage could be ‘Rejected’ or ‘Cancelled’), unless it moves onto another ongoing process	Task will most likely not need to be completed since they are non-actionable, unless in cases that the reference / resource is no longer available / deprecated / outdated etc. then it could be marked complete
Sections	Listed in chronological order, usually referring to the Stages / Phases of the project. Tip: when all tasks within a section are completed, collapse the section and save view	Instead of creating Sections, use the Group button to display groups based on a single-select field such as Stage / Status (more here). Another good alternative is to group by Custom task types (see below)	There is a fair chance you could either use Sections or instead Group by a custom field
Assignee	Assign all tasks once the assignees are known (in most cases, the assignee is unlikely to change during a task’s lifespan)	Assignee may change as task moves between columns eg. stages / status	Since tasks are not actionable, no need to set assignees so best to hide the Assignee column from List views
Due date	Set due date to all tasks once known (may potentially shift during task’s lifespan)	Due date may likely shift as task moves between columns eg. stages / status	Since tasks are not actionable, no need to set due dates so best to hide the Due date column from List views
Start date	Set start date to define a task’s duration (may potentially shift during task’s lifespan)	Unlikely to be used	Since tasks are not actionable, no need to set start dates so best to hide the Due date column from List views
Recurring tasks	Unlikely to be required since tasks will be unique, not repetitive	Potentially used for repetitive tasks that go through the same process	Unlikely to be used
Dependencies	Create dependencies between tasks leading up to milestones and ideally throughout entire project in order to show the Critical Path in Gantt view	Unlikely to be used	Unlikely to be used
Subtasks	Use to break up tasks into smaller steps. Tip: use assignee and due date if delegated to several people, otherwise leave blank if subtasks are used as checklist items for the parent task’s assignee.	Could be used although may add unnecessary complexity and you may discover limitations such as rules not capable of taking action on the parent task	In rare cases, they could potentially be used to break up reference tasks, although not recommended

Task types

Feature	Project type A: Deadline-bound	Project type B: Ongoing Process	Project type C: Reference
Milestones	Best placed at the end of each section / stage / phase of the project, used as markers that will surface in the project’s Overview tab, a Portfolio’s List & Timeline tabs and count towards the progress of connected Goals	Unlikely to be used	Unlikely to be used
Approvals	Best used for interim reviews or at the end of stages, before milestones	Could be used although may add unnecessary complexity; instead, define as options within a single-select field, as stages / status of the process	Unlikely to be used
Custom task types	Unlikely to be used	Ideal for self-contained workflows (because they are part fo a specific project, not global) and a good alternative to grouping by a single-select field	Unlikely to be used

Layout and view options

Feature	Project type A: Deadline-bound	Project type B: Ongoing Process	Project type C: Reference
Filter	Set Incomplete tasks in the default view for better clarity and to reduce scrolling	Likely to be used based on task types or fields, relevant to the view tab. Filter for incomplete tasks may not be required if there is a group for completed tasks	Likely to be based on fields since there will be no completed tasks
Sort	Sort by due date in the default view to list tasks chronologically	Likely sort by due date or by creation date to see latest added tasks	Likely to be used, based on fields
Group by	Likely not be used because project will be grouped by Sections but could be used to add a subgroup	Group by a single-select field such as Stage / Status (more here)	There is a fair chance you could either Group by a custom field or instead use Sections
Show/hide fields	In List view, arrange field columns in order of priority and consider hiding any fields that do not need to be updated often. Tip: keep the Assignee and Due date fields always first and then any custom fields on the right, so all projects are familiar to all users	In a Board view that is grouped by the stage / status field, hide that field (see step 5 here) as well as any other ‘secondary’ fields to reduce visual clutter on your task cards	Since tasks are not actionable, hide the Assignee and Due date columns from any List views

Saved view tabs

Feature	Project type A: Deadline-bound	Project type B: Ongoing Process	Project type C: Reference
Saved view tabs	Could be used for alternative List views, e.g. grouped by Due date or filtered to show ‘Just my tasks’, but perhaps not ideal if projects are created from Project Templates, which do not currently support saved view tabs	Definitely invest time in tailoring all saved view tabs in such perpetual projects - make it work for all members	Could be used to present / organize list of tasks based on various fields
Overview	Use to populate Project description and Key resources, view Project roles, Milestones, Connected Goals & Portfolios, Status updates, Project summary and project creation date and due date	Could be used but unlikely to have any Milestones, Connected Goals or Portfolios, Status updates or a project due date	Unlikely to be used
List	Most likely set as the default view	Possibly set as the default view	Most likely set as the default view
Board	Not ideal since tasks will not move left to right, from one column to another - remove it	Most likely set as the default view since tasks will move left to right, from one column to another	Could potentially be used if graphics are attached to tasks to appear as thumbnails on each task card
↔️ Timeline / Gantt	Possibly set as the default view; useful for shifting task due dates and creating and managing dependencies	Unlikely to be used	Unlikely to be used
Calendar	Not ideal - use Gantt or Timeline instead	Likely to be used	Unlikely to be used
Dashboard	Likely to be used for detailed progress, status and tracking cost / time	Definitely used to provide insights and statistics, time spent in statuses / stages, useful for SLAs	Could be used to display insights if project is used for data collection such as feedback, surveys, CRM
Note	Potential for meeting notes or additional resources, easier accessible than the Overview tab	Unlikely to be used	Potential for additional references, easier accessible than the Overview tab
Messages	Potential usage but remove it if members are using other channels such as Slack or MS Teams	Potential usage but remove it if members are using other channels such as Slack or MS Teams	Potential usage for Q&A
Files	Potentially useful if project has numerous attachments	Potentially useful if project has numerous attachments	Potentially useful if project has numerous attachments
Workflow	Unlikely to be used	Unlikely to be used - instead, use the custom rule builder with conditional branching	Not required since tasks will not be actionable
Workload	Potential usage to see workload of all assignees within the project, although this provides a fairly ‘narrow’ view	Potential usage to see workload of all assignees within the ongoing workflow	Not required since tasks will not be assigned

Customize menu

Feature	Project type A: Deadline-bound	Project type B: Ongoing Process	Project type C: Reference
Fields	Use to capture properties of each task such as Status, Priority, Estimated & Actual time, Cost etc but highly recommended to keep to a minimum because fields such as Status require constant manual update - on the other hand, fields such as Estimated time could be pre-populated within a template so no manual input required in the live project	Use to capture properties of each task such as Status, Priority, Estimated & Actual time, Cost etc but highly recommended to keep to a minimum to reduce manual input and avoid redundancy / unreliability	Use to categorize tasks or other properties such as links or other data points
Rules	Potentially used for basic actions such as for example, set status complete when task is complete, or add all tasks added, to a master project	Definitely used to trigger actions as a task moves from one stage / status to another, such as change assignee, shift due date by X days, send a comment etc. Tip: avoid using rules to sync moving tasks into sections with their corresponding status; instead of using Sections, Group by the status field (more here)	Not required since tasks will not be actionable
Forms	Unlikely to be used; create a dedicated project for each form, avoid combining tasks created from forms with such projects	Should ideally be used as the primary intake method of tasks being created, providing a standardize intake process	Could be used in cases of feedback surveys or data collection for non-actionable tasks
Apps	Could be used, depending on the nature of the project	Could be used, depending on the nature of the project	Unlikely to be used
Task templates	Unlikely to be used because tasks are usually unique and not repetitive	Likely used for repetitive tasks, either complimentary to, or as an alternative to using a form	Could potentially be used for repetitive reference tasks
Bundles	Definitely to be used, especially if the project is created from a Project Template	Although rare, because processes are usually unique, Bundles could be used to standardize similar workflows and processes	Unlikely to be used

Project Actions & Insights

Feature	Project type A: Deadline-bound	Project type B: Ongoing Process	Project type C: Reference
Save as template (Project Templates)	Ideal for easily creating a new instance of the project, using dynamic roles and due dates	Could potentially be used for similarly structured ongoing processes, likely without any contents (tasks)	Could potentially be used for similarly structured reference projects, likely without any contents (tasks)
Duplicate project	Could be used to create a copy with shifted due dates	Could be used instead of Project Templates when there are no tasks and it’s important to copy saved view tabs and dashboards (which Project Templates do not currently support)	Could be used instead of Project Templates when there are no tasks and it’s important to copy saved view tabs and dashboards (which Project Templates do not currently support)
Status updates	Ideal to provide notifications and insight on the project’s progress and health, which will also surface in the project’s Overview tab, a Portfolio’s List tab and within connected Goals	Unlikely to report on the progress or health of an ongoing process	Unlikely to report on the progress or health of a reference type project
Add to a Portfolio	Ideal to surface Status updates, and especially if projects are created from a Project Template (which can be be set from the Project Template’s settings)	Unlikely to be used because ongoing processes will not report on Status Updates and also because they are usually unique in nature	Could be used to group various reference type projects. Tip: Task progress column should be hidden since tasks will not be completed
Connect to a Goal	Ideal if a project counts towards a Goal’s progress, either by number of tasks or milestones completed	Unlikely because an ongoing process’ task count will bever be completed or reach 100%	Unlikely for a recourse type project to count towards a Goal’s progress
Add to a Capacity plan	Ideal for allocating upcoming projects to members	Unlikely to allocate ongoing processes to members	Unlikely to be allocate reference projects to members

I hope you enjoyed this thread as much as I enjoyed finding an emoji for each Asana feature

Let me know if you have any questions about any features, or any that I missed, that should be compared between the three project types.

Richard Sather
Asana Expert, Consultant and Trainer

See all of my top tips & tricks on my website.

[lpb]

What a wealth of practical information all in one place–thanks for creating this comprehensive resource! I’m sure many would quibble over a number of points, but for those looking for a starting point or rules of thumb, it’s a valuable resource.

Of course, I can’t resist offering a couple of minor suggestions for change, if you haven’t already discounted them:

The Basics > Sections > Ongoing Processes > Instead of creating Sections, use the Group button to display groups based on a single-select field such as Stage / Status (more here):

• In addition to mentioning single-select custom fields, add custom task types as well as a sometimes even more streamlined way to group tasks, change stages, and avoid unnecessarily rules.

Task types > Deadline-bound > Milestones > Best placed at the end of each section / stage / phase of the project, used as markers that will surface in the project’s Overview tab, a Portfolio Timeline tab and count towards the progress of connected Goals:

• Also mention Milestones’ value in Portfolio List view Milestone Program column cells.

Saved view tabs > Saved view tabs > Deadline-bound > Could be used but not ideal if projects are created from Project Templates, which do not currently support saved view tabs:

• I find extra tabs in these kinds of projects to be invaluable, particularly List by Start/Due Date, List by Team, List for Me, etc. to complement the overall default List view by phased section groups.

Customize menu > Fields > Deadline-bound and Ongoing Process:

• I usually discourage use of Status and Priority custom fields for a variety of reasons, including redundancy, unreliability (too much to keep up), etc.

But again, these are minor (and the last one perhaps controversial) points compared to the great overall value of the resource you created.

Thanks,

Larry

[Richard_Sather]

Thanks @lpb , I can always count on your thoughtful feedback!

Sections > Ongoing Processes> Good point! I mentioned this in the Custom task types below so I’ve also mentioned them in Sections now.

Milestones>Deadline-bound> Yes, of course - how did I miss that?

Saved view tabs > Deadline-bound > I don’t disagree so I’ve toned down my ‘negativity’ towards this approach - I would obviously feel different if Templates supported saved view tabs

Fields > Deadline-bound and Ongoing Process> Yes, this once is perhaps a bit controversial although you do have a very valid point so I have adjusted these two to reflect that.

Thanks again for the feedback - it’s made this article even better.

[Lina_Moreno]

Hi @Richard_Sather, thank you for this comprehensive resource!

I was wondering about the workflow feature. I see it’s not recommended for any project type. When would you recommend using the workflow feature then? Or do you recommend never using it?

Thanks!

[Richard_Sather]

Hi @Lina_Moreno , thanks for your kind words!

Great question - the Workflow builder tab was introduced several years ago but it relies on Sections and tends to generate numerous rules.

Since then, Asana’s Rules have introduced conditional branching which is a far better way to visualise an entire workflow and much easier to manage than the Workflow tab because one rule can act in place of numerous rules.

For these reasons, I consider the Workflow tab deprecated and thus I’m not surprised it’s no longer part of the default tabs during the project creation process.

[Paula_Holsberry]

Wow, Richard. This is an amazing and comprehensive resource! Thank you for generously sharing it with us.

[Richard_Sather]

Thanks @Paula_Holsberry !
My pleasure