Reporting from Asana: Five Dashboards Every Operations Leader Should Build

The default Asana reporting view is fine for a project lead and useless for a department head. Five dashboards we set up for every leadership team — what each one answers, how to build it, and the fields that make it possible.

AsanaFLOWPATH Team18 February 202610 min read

The default reporting view in Asana is fine for a project lead and useless for a department head. A project lead wants to know what's overdue in their project; a department head wants to know whether the function is on track, where the bottlenecks are, and which initiatives are at risk before the executive meeting on Thursday. Those are different questions and they need different dashboards.

Asana has the reporting capability — Universal Reporting, Portfolios, and dashboard widgets — but the build patterns aren't obvious. These are the five dashboards we set up for every operations leader we work with. Each answers a specific question, and together they replace the weekly status deck.

Dashboard 1: The portfolio health view

Question it answers: which initiatives are at risk?

Build: a Portfolio of every active project the leader cares about. Show status (On Track / At Risk / Off Track), owner, due date, and one custom progress field. Sort by status descending so red items rise to the top.

What makes this dashboard work is the discipline of project owners actually posting status. If everything is permanently green, the dashboard is decorative. A working rule: every project owner posts a status update every Monday before noon. If the leader sees stale statuses, they ask the owner directly. Two weeks of that and the discipline holds.

Dashboard 2: Overdue and at-risk tasks across the function

Question it answers: where is work piling up that shouldn't be?

Build: an Advanced Search saved as a report. Filter on:

  • Tasks assigned to anyone in your team(s).
  • Due date is in the past.
  • Not completed.

Group by assignee. The view immediately shows who has the backlog. Counts matter here — anyone with more than ten overdue tasks isn't bad at their job, they've got a workload or prioritisation problem that the leader needs to address directly.

A nice extension: a second saved search for tasks due in the next seven days, grouped by assignee. This is the “is anyone about to drown next week?” view.

Dashboard 3: Cycle time by stage

Question it answers: where in our workflow is work getting stuck?

Build: this one requires that your recurring workflow projects use a consistent Stage custom field (Brief / In Production / Review / Approved / Live, or your equivalent). Once you have that, use Universal Reporting to chart average days-in-stage over the last 90 days.

The interesting finding, almost every time we build this: the bottleneck is in Review, not Production. The team isn't slow at making things; the organisation is slow at deciding on them. That single chart, shown once, often changes the leadership conversation about “why is marketing slow” or “why does ops take so long” in productive directions.

Dashboard 4: Intake volume and disposition

Question it answers: are we keeping up with what's being asked of us?

Build: requires a request intake project fed by a form. Chart:

  • Requests submitted per week (line chart).
  • Requests by disposition: accepted, declined, deferred, in-progress, completed (stacked bar).
  • Average days from submission to triage decision.

This dashboard is invisibly important. It's the basis for saying “no” in a way that's defensible — “we received 47 requests this month, declined 12 of them for these specific reasons, deferred 8 to next quarter.” Without it, every “no” feels personal. With it, no's are policy.

Dashboard 5: Capacity and load by person

Question it answers: who's overloaded and who has capacity?

Build: workload view at the team level, with the Effort estimate custom field driving the load calculation. Filter to the next two weeks. Sort by load descending.

This is the dashboard most teams build last because it requires the team to estimate work — which is a separate discipline problem. The honest path: introduce effort estimates first for campaign and project work (where the team is already used to them), then expand to BAU once the habit is established.

For teams not yet using effort estimates, a useful proxy is just “active tasks per assignee.” It's blunt but directionally honest, and it's a foothold for the more nuanced view later.

A few configuration mistakes that ruin the dashboards

  • Inconsistent custom fields.If half your projects call it “Stage” and the other half “Status,” reporting breaks. Use workspace-level global fields.
  • Project ownership ambiguity.Reports rely on there being one project owner. Multi-owner projects can't be statused cleanly.
  • Status updates posted to slides, not Asana.If the project status lives in a Friday deck, the dashboard is permanently out of date. Move statuses into Asana entirely or accept the dashboard is decorative.
  • Completed tasks not actually being marked complete.Sounds trivial; isn't. The weekly team-level habit of clearing the completed-but-not-marked backlog is what keeps reports honest.

The reporting plan you should actually build

Don't try to build all five dashboards on day one. The operating leader who shows up with five dashboards in week two signals a process obsession that erodes trust. A staged build:

  1. Week 1–2: Dashboard 1 (portfolio health). Establish the weekly status-posting habit.
  2. Week 3–4: Dashboard 2 (overdue / at-risk). Use it in one-on-ones, not in public, until owners trust it.
  3. Month 2: Dashboard 3 (cycle time). Use the findings to make one concrete process change. The change is what earns the dashboard's credibility.
  4. Month 2–3: Dashboard 4 (intake). Probably depends on intake form discipline being in place first.
  5. Month 3+: Dashboard 5 (capacity). Layer on once effort estimates are habitual.

Where Asana's reporting falls short (and what to do)

Honest assessment: Asana's native reporting is good, not great. It handles the five dashboards above well. It struggles when you need:

  • Cross-workspace reporting at the enterprise level.
  • Joining Asana data with external data (finance, CRM).
  • Trend analysis over more than a year.

For those, export to your BI tool of choice (Looker, Tableau, Power BI) via the Asana API or a connector. We'd generally wait until you have at least 50 active users before investing in that — under that size, native reporting is plenty.

The honest bottom line

Five dashboards, built sequentially over a quarter, will replace most of a weekly status deck. The hard part isn't the configuration; it's the operating habits underneath — consistent custom fields, real status updates, weekly cleanup. Get those right and Asana's reporting earns the “source of truth” label it's often promised but rarely delivered.