Asana Project Features Overview for 2025: What to Use and When

If you want to get the most out of Asana, it helps to know which features to use — and how to use them — based on the kind of project you’re managing.

This Asana project features overview for 2025 is based on years of hands-on work with teams across industries. I’ve found that nearly every project fits into one of three broad patterns, and once you identify the type, it becomes much easier to choose the right structure, fields, views, and automations to support it.

Whether you're managing deadlines, running an ongoing process, or organizing reference material, this guide will help you use Asana’s features in a way that’s clear, focused, and tailored to the work.

The three common project types:

Project Type	How It Works	Best For
🎯 Deadline-bound	A series of tasks that lead to a clear outcome. The project ends when the goal is complete.	Campaigns, launches, onboarding
🔄 Ongoing Process	A repeatable flow where tasks move through stages. The project stays open.	Helpdesks, content requests, agile sprints
💡 Reference	A static project for storing information. Tasks are rarely assigned or completed.	SOPs, CRMs, training materials

You don’t need to force every project into a category, but thinking this way helps you choose the right features for the job.

Project features overview: what to use and when

Each type of project has its own logic. A launch plan benefits from a fixed structure. A helpdesk needs to handle a constant flow. A training library should be clean and easy to browse.

Feature	🎯 Deadline-bound	🔄 Ongoing Process	💡 Reference
✔️ Tasks	✅ I suggest listing tasks in order of execution, where each one represents a step leading to a larger outcome.	✅ I recommend treating each task as a separate unit of work that moves through a defined workflow.	✅ Each task can serve as a record or entry — not something intended to be acted on.
🌟 Task Creation	✅ These tasks are typically added manually or through a project template.	✅ Benefits from being created via Forms or Task Templates to maintain consistency.	✅ Best created manually by owners or editors, ideally following a structured naming or tagging convention.
✅ Task Completion	✅ Mark tasks complete when the work is done — often tied to milestones or reporting.	✅ Completion tends to reflect the end of a process, whether the task is completed, rejected, or transferred.	⚖️ These tasks rarely need to be completed unless the entry becomes outdated or deprecated.
📑 Sections	✅ I recommend using Sections to represent phases or stages of work. Once all tasks in a section are complete, consider collapsing it to keep things tidy.	❌ In this setup, I suggest avoiding Sections and instead grouping tasks by a single-select field such as Status or Stage.	⚖️ Either Sections or field-based grouping can work here — it depends on how structured the data needs to be.
👤 Assignee	✅ Assign at the start. The person usually stays the same.	✅ Often reassigned as the task moves between stages.	🙈 Since these tasks aren’t actionable, hide the Assignee field to reduce visual clutter.
📅 Due Date	✅ Add once confirmed. Can be used for scheduling, reminders, and reports.	✅ Due dates often shift as work progresses.	🙈 These are rarely necessary in reference projects. I recommend hiding the field unless sorting or filtering requires it.
📅 Start Date	✅ Helpful when defining task duration or visualizing workload in Timeline view.	❌ In most process-based projects, I find start dates aren’t needed.	🙈 Not applicable for reference-style setups — best to hide the field.
🔁 Recurring Tasks	❌ Not typically useful here, since tasks are usually unique to the project outcome.	⚖️ May be helpful for regular, repeated work like weekly reviews or check-ins.	❌ Not relevant in reference projects.
⌛ Dependencies	✅ I suggest using dependencies to show sequencing — especially in Timeline or Gantt view or when working toward milestones.	❌ In this model, dependencies usually aren’t helpful.	❌ Not relevant, since tasks don’t relate to each other in this format.
↪️ Subtasks	✅ Can be helpful for breaking down tasks or handling partial delegation. If used purely for clarity, leave them unassigned.	⚖️ Can work, but may reduce visibility or rule compatibility — I suggest using sparingly.	❌ I recommend avoiding subtasks here — they add unnecessary complexity to static content.

Task types: use them where they add value

Asana allows you to create Milestones, Approvals, and Custom Task Types. These are best used with intent. Deadline-based projects often benefit the most, while reference projects usually don’t need them at all.

Feature	🎯 Deadline-bound	🔄 Ongoing Process	💡 Reference
🔷 Milestones	✅ I recommend placing milestones at the end of each section, stage, or phase to serve as clear markers of progress. These will surface in the project’s Overview tab, Portfolio List, and Timeline views, and contribute to connected Goals.	❌ Milestones are generally unnecessary in this type of project.	❌ Not typically relevant — reference projects don’t track progress in this way.
✅ Approvals	✅ Best used for key decision points or reviews — especially near the end of a stage, before moving to the next milestone.	⚖️ Can be used, but may add unnecessary complexity. I often suggest using a single-select field to represent stages or statuses instead.	❌ Not recommended — these projects aren’t task-driven and don’t require formal approvals.
☑️ Custom Task Types	❌ These don’t tend to add value in deadline-driven projects.	✅ I recommend using custom task types for clearly defined workflows — especially when you want to visually distinguish different types of work within a single project. A good alternative to grouping by fields.	❌ Custom task types usually don’t apply here, since the tasks themselves aren’t active work items.

Saved views & navigation

Asana gives you several built-in ways to view your work — including List, Board, Gantt, Calendar, and Dashboard — plus the ability to save custom views as tabs. I recommend choosing views based on how the project functions. For example, process-driven boards usually benefit from a Kanban-style Board view, while deadline-based projects often rely on List or Timeline. Reference projects may need very little beyond a clean List. Below, you'll find suggestions on which views to show, hide, or prioritize depending on your setup.

Feature	🎯 Deadline-bound	🔄 Ongoing Process	💡 Reference
➕ Saved View Tabs	⚖️ Can be used to create alternative views, such as grouping by Due Date or filtering to show “Just my tasks.” Less useful if you're relying on project templates, which don’t preserve saved tabs.	✅ I recommend investing time in tailoring these — they’re ideal for long-running, collaborative processes where different views help different roles.	⚖️ Can help organize reference material using different filters or groupings — particularly if multiple teams access the same project.
📋 Overview Tab	✅ Use to add a clear project description and key resources. Also helpful for surfacing project roles, Milestones, connected Goals, and Portfolios.	⚖️ Can be useful for context and links, though many of the project-level features (Milestones, Status Updates) may not apply.	❌ Typically unnecessary — these projects don’t track progress and may not require a formal Overview.
📃 List View	✅ Most likely your default view. Works well for structuring tasks chronologically or grouping by Section.	✅ Can be used as default or secondary view, especially when filters or sorts are important.	✅ Works well for displaying structured reference data.
🎴 Board View	❌ Not ideal — these projects don’t move from left to right in stages. I suggest removing it unless absolutely needed.	✅ Often the best default view, since tasks typically flow from left to right through defined stages.	⚖️ May be used if tasks include visual content (e.g. thumbnails), or to present categories visually.
↔️ Timeline / Gantt	✅ I suggest using this view for visual planning, adjusting dates, and managing dependencies. It’s especially helpful when sequencing matters.	❌ Rarely needed — workflows tend to be continuous and managed by status, not by time.	❌ Not applicable for static content or non-actionable records.
📅 Calendar View	❌ Usually redundant if you’re already using Timeline.	⚖️ Can be helpful if tasks are time-sensitive or tied to specific due dates.	❌ Not needed for non-time-based tasks.
📊 Dashboard	⚖️ Can be used to surface key metrics — especially around timeline, cost, or completion.	✅ Highly valuable for tracking task volume, turnaround time, or time spent in each stage. Great for SLA visibility.	⚖️ May be used if the project collects structured data, such as survey results or CRM info.
📄 Notes	⚖️ Can be used for meeting notes or supplementary info — often quicker to access than the Overview tab.	❌ Not commonly needed unless your process includes regular documentation.	⚖️ May be useful for storing extra reference material, Q&A, or related resources.
💬 Messages	⚖️ Can be helpful for high-level announcements — but if you use Slack or Teams, consider removing it.	⚖️ Same advice here — it’s available, but not always the best communication channel.	⚖️ Might be used as a Q&A area or discussion space for shared reference.
📎 Files	⚖️ Consider using if your project includes many attachments and you want a centralized place to browse them.	⚖️ Can be helpful when forms or processes result in multiple uploaded assets.	⚖️ May be useful for storing relevant documentation in one place.
➡️ Workflow	❌ Not typically needed. If you want automation, use rules directly in the Customize menu.	❌ Same goes here — rules with conditional logic are often a better fit.	❌ Not required, since there’s no active task flow to automate.
📈 Workload	⚖️ Can be used to get a high-level sense of team allocation — though it’s often limited to the current project scope.	⚖️ May be useful if all team tasks live in one project, though Portfolios generally give a better cross-project view.	❌ Not relevant, since tasks aren’t assigned or time-bound.

Layout & view options

Once you've picked the right view, how you configure it can make or break usability. Filters, sorting, grouping, and field visibility help reduce clutter and make key details easier to spot. The suggestions below offer a starting point for tailoring your layouts based on the type of project — whether you're tracking deadlines, managing workflows, or maintaining a reference database.

Feature	🎯 Deadline-bound	🔄 Ongoing Process	💡 Reference
🥛 Filter	✅ I suggest setting the default filter to show Incomplete tasks — this helps reduce visual clutter and makes it easier to focus on what’s left to do.	⚖️ Filtering can be helpful depending on the fields and view type. If completed tasks are grouped separately, filtering may not be necessary.	⚖️ Filtering is often based on custom fields rather than completion status, since most tasks won’t be completed.
↕️ Sort	✅ Sort tasks by Due Date in the default view to show them in chronological order — especially useful for planning and reviews.	⚖️ Sorting by Due Date or Creation Date can be helpful to prioritize or track new requests.	⚖️ Sorting is still useful — typically based on fields like Name, Category, or another metadata point.
📑 Group by	⚖️ You may not need to group tasks if you're already using Sections, but it can help highlight subcategories or workstreams.	✅ I recommend grouping tasks by a single-select field like Stage or Status — it helps visualize progress without relying on Sections.	⚖️ Either approach can work depending on the structure — grouping by fields often adds flexibility if consistent naming is used.
👁️ Show/hide fields	✅ In List view, I recommend ordering columns by priority and hiding any that don’t need frequent updates. Keep Assignee and Due Date visible early, followed by custom fields. This helps keep layouts familiar across projects.	✅ In Board view, I suggest hiding the field used to group tasks (e.g. Stage or Status) along with any less-relevant metadata to reduce clutter.	✅ Since these tasks aren’t actionable, I recommend hiding Assignee and Due Date fields entirely — focus on the fields that provide reference value.

Customize menu

The Customize menu is where you configure the moving parts of an Asana project — fields, forms, task templates, rules, and integrations. I suggest approaching this menu as your toolkit for shaping how tasks behave and how work enters the system. For example, Forms help standardize intake, while Rules can automate routine actions like assigning tasks or updating statuses. You can also connect third-party tools using the Apps menu, such as Slack, MS Teams, or Google Drive.

On Enterprise plans, Bundles let you apply the same combination of fields, rules, sections and task templates across multiple projects at once — helpful if you’re standardizing processes at scale.

Below are my recommendations on which tools to use depending on the project type.

Feature	🎯 Deadline-bound	🔄 Ongoing Process	💡 Reference
🔽 Fields	✅ I suggest using fields to track things like Status, Priority, Estimated Time, or Cost — but keep it lean. Anything that requires frequent manual updates can add friction, so lean on pre-filled values from templates where possible.	✅ Fields are useful for tracking stage, priority, or effort. I recommend using them selectively to reduce overhead and improve consistency.	✅ Use fields to tag or categorize records, add links, or highlight key metadata. Since tasks aren’t actionable, there's usually no need to update these fields frequently.
⚡ Rules	⚖️ Rules can help with basic actions — for example, setting Status to complete or auto-adding tasks to a master project.	✅ I strongly recommend rules here. They’re ideal for process handoffs — like changing assignee, updating fields, or posting comments as a task moves through the workflow.	❌ Usually unnecessary, since these tasks don’t follow a process or trigger updates.
📝 Forms	❌ Not a good fit — if you need a form, I suggest creating a dedicated intake project, separate from your main delivery project.	✅ Forms are a great way to standardize task creation. I often recommend them as the primary entry point for incoming work.	⚖️ Can be useful for surveys, feedback, or other structured data collection — especially if tasks are just placeholders for responses.
📱 Apps	⚖️ Can be useful depending on the nature of the project — for example, if integrating with time tracking or calendars.	⚖️ May help connect tools like Slack or email with incoming tasks. Use case depends on the workflow.	❌ Often not necessary, unless the app serves a purely reference or documentation role.
☑️ Task Templates	❌ Not usually needed — tasks are often unique to each project instance.	✅ I recommend using templates for repeated request types. They work well alongside Forms or on their own.	⚖️ Could work for adding consistent structure to frequently repeated records, such as client profiles or location entries.
🎛️ Bundles	✅ A great fit when using Project Templates — I suggest setting them up to apply common fields, rules, and settings consistently.	⚖️ Rare, but may be helpful to standardize similar workflows across multiple process-type projects.	❌ Not needed — reference projects usually don’t benefit from preconfigured bundles.

Project actions & insights

Once your project is up and running, Asana gives you several ways to standardize, monitor, and align your work across teams.

• Templates and Duplicates: Use Project Templates to create repeatable structures with prefilled roles, sections, and dates. If you need more flexibility — like retaining saved views or dashboards — duplicating a project can be a better fit.

• Visibility and Reporting: Built-in Status Updates let you communicate project progress and feed into the Portfolio view, which gives a high-level summary of multiple projects at once. These updates can also roll up to Goals, helping teams align execution with larger objectives.

• Planning and Resourcing: On Enterprise plans, Capacity Plans let you allocate people to entire projects (not just tasks), giving you a broader view of how team members are staffed across timelines.

Each of these features supports a different kind of project outcome. Below, I’ve outlined where I recommend using them — and where they may not add value.

Feature	🎯 Deadline-bound	🔄 Ongoing Process	💡 Reference
📰 Save as Template	✅ Very useful for spinning up repeatable projects. I suggest including dynamic roles and date offsets for flexibility.	⚖️ Can be used to create a consistent shell for similar process projects — just exclude tasks and customize per use case.	⚖️ May be helpful for building clean, pre-structured reference projects.
➕ Duplicate Project	⚖️ A good workaround for cases where you need to shift dates or reuse views — especially if Project Templates don’t cover everything.	⚖️ Works well when templates fall short — particularly if you want to retain Saved Tabs or Dashboards.	⚖️ Same as above. Helpful if the structure is stable and you want to duplicate the layout without repopulating tasks.
🚦 Status Updates	✅ I recommend using this to report on project progress. It integrates with Goals, Portfolios, and the Overview tab.	❌ Not useful here — ongoing workflows don’t have an end state to report against.	❌ Not applicable — reference projects aren’t tracked for progress.
📂 Add to Portfolio	✅ Ideal if the project is part of a larger initiative. I often include deadline-based projects in Portfolios for reporting and oversight.	❌ Rarely needed — process-type projects are usually operational and don’t require high-level monitoring.	⚖️ Could be used to group reference libraries together. If you do, I suggest hiding the task progress column.
🔼 Connect to a Goal	✅ Great for aligning project output with measurable objectives. Tasks and milestones can both count toward progress.	❌ Not relevant — these projects don’t complete in the traditional sense.	❌ Doesn’t apply — reference content doesn’t contribute to goal completion.
🔮 Add to Capacity Plan	✅ Useful for planning workload across teams, especially when scheduling multiple projects.	❌ Not needed — operational work isn’t typically time-boxed at the project level.	❌ Not relevant — reference projects don’t involve resourcing.

Final thoughts: why setup matters

There’s no single best way to use Asana — but there is a smart way to use its features based on project purpose. This Asana project features overview is designed to help you skip the noise and zero in on the settings that matter most for your team.

By choosing your features intentionally, you can build projects that are more focused, easier to maintain, and better suited to the kind of work you're managing.

Need help tailoring your workspace or deciding which features to standardize?

👉 Book a free consultation and I’ll walk you through it.

P.S. This blog post is adapted from a forum post I originally shared in May 2025 here. If you’re active in the community, feel free to join the conversation there too!