Finding Resolution Rate (90d), Asana

Metrics type: Key Metrics • Category: Project Management

At a glance

The percentage of VortexIQ findings created in the last 90 days that have been resolved (Asana task marked complete). It is the team’s batting average against the audit programme. Below 50% the team is falling behind; above 75% the team is matching or beating intake. This is the single number that compresses Findings Open, Abandoned, and Time-to-Fix into one merchant-readable score.


The formula	`resolved_in_window ÷ created_in_window`, where `resolved_in_window` counts Asana tasks with `vortexiq_finding_id` and `completed = true` and `completed_at` within the 90-day window, and `created_in_window` counts tasks with `vortexiq_finding_id` and `created_at` within the same window.
API endpoints	`GET /tasks` paged with `opt_fields=created_at,completed,completed_at,custom_fields`. We bucket by `vortexiq_finding_id` to avoid double-counting if a finding was re-created.
Window	Rolling 90 days, refreshed hourly. Real-time refreshes happen on every webhook event for the live count, but the rate calculation is hourly to smooth out single-task volatility.
What “resolved” means	Asana `completed = true`. We do not separately count “Won’t Do” closures (Asana represents these as completed tasks regardless of section), so a finding closed as “Won’t Do” counts as resolved. This is intentional: from the audit programme’s perspective, both decisions (fix it, decide not to fix it) are resolutions.
Project / workspace scope	All `vortex_iq_outbound` projects across all connected Asana workspaces.
Archived projects	Excluded from both numerator and denominator.
Time zone	UTC for both `created_at` and `completed_at`. The 90-day window aligns to UTC.
Alert trigger	`< 50%` raises a critical alert. The 50% threshold reflects the empirical break-even point: below 50% the open queue compounds week-over-week; above 50% it stabilises.
Sentiment thresholds	Gauge: green ≥ 75%, amber 50-74%, red < 50%.
Multi-workspace aggregation	Yes, computed on the summed numerator and denominator across all connected workspaces. Per-workspace stack panel available.
Roles	owner, operations

Calculation

Calculated automatically from your Asana data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

Worked example

A specialty-coffee DTC brand on Shopify, marketing-led, 12-person team. Asana is the team’s primary planning tool. Snapshot taken on 02 May 26 at 10:30 BST.

Last 90 days (02 Feb 26 - 02 May 26)	Count
Findings created (Asana tasks with `vortexiq_finding_id`, `created_at` in window)	84
Findings resolved (above set, AND `completed = true`, `completed_at` in window)	53
Findings still open from window	26
Findings re-opened during window	5 (counted once in numerator, on first close)

Resolution rate = 53 ÷ 84
                = 0.631
                = 63.1%, displayed as 63%

What the merchant should read into this:

63% sits in the amber band (50-74%). Above the alarm threshold but below the green-zone target. The team is closing more than it is opening, but slowly enough that the open queue shrinks by only one task per week net. Acceptable, not great.
The open queue will not collapse to zero. At 63% resolution rate, expect roughly 30-40 open findings as a steady-state, anything beyond that is the team falling behind, anything below it is the audit programme finding less than usual.
Pair this card with Avg Time-to-Fix. A 63% rate with a 7-day mean time-to-fix is healthy; a 63% rate with a 28-day mean time-to-fix means the team is closing easy items and stalling on hard ones.
Compare against Findings Open trend. If open count is rising for three weeks while resolution rate sits at 63%, the audit programme is producing more findings than the team can absorb, a calibration issue with the audit, not a team problem.
The team should aim for 75% sustained. Below 50% is alarm territory; above 75% means the team is keeping up with intake. Most healthy mid-market merchants live at 65-80% on a marketing-led PM tool like Asana. Engineering-led tools like Linear typically run higher (80-90%) because engineering teams have stricter completion definitions.

Sibling cards merchants should reference together

Card	Why pair it with Resolution Rate	What the combination tells you
VortexIQ Findings Open	Resolution rate’s denominator-half. Open count grows when this rate falls.	Falling rate + climbing open count = capacity bottleneck; falling rate + flat open count = audit programme is finding less.
Abandoned Findings (>14d)	Tasks that count as denominators but never become numerators.	High abandoned + low rate = execution discipline gap; low abandoned + low rate = the team is engaged but underwater.
Avg Time-to-Fix (days)	Time-to-fix is the cycle time inside this rate.	High rate + low time-to-fix = excellent; high rate + high time-to-fix = the team is closing items eventually but slowly.
Tickets Resolved (7d)	Short-window throughput of all tasks (not just findings).	If overall throughput is high but findings rate is low, audit work is being deprioritised.
Sprint Velocity (avg)	Velocity is the team’s capacity ceiling.	A flat rate with rising velocity = the audit work isn’t reaching sprints.
Throughput Trend	Tells you whether the team’s pace is accelerating or decelerating.	A rate dipping while throughput climbs = a deliberate prioritisation away from audit work.
Sprint Progress	Whether findings are getting committed to the current sprint.	Low sprint progress + low rate = findings are queued but never pulled in.

Reconciling against the vendor’s own dashboard

Where to look in Asana’s own UI:

app.asana.com then for each vortex_iq_outbound project open Reporting (formerly Dashboards) and add a Tasks completed chart filtered by Custom Fields → vortexiq_finding_id → is set, with the time range set to Last 90 days. The Asana Goals module also surfaces a similar completion-rate gauge for projects with goals defined; the math is comparable.

Asana does not natively expose a single resolution-rate number; the closest is the Tasks completed vs Tasks created twin chart in Reporting. The arithmetic is the same as ours. Why our number may legitimately differ from Asana’s Reporting twin chart:

Reason	Direction	Why
Window definition	Either	Asana’s Reporting “Last 90 days” rolls daily at midnight in your account-profile timezone; our window rolls hourly in UTC. For a number that updates hourly the difference is small, but if you check at 23:00 local one day and 00:30 local the next, Asana’s denominator may shift by a calendar day.
Re-created findings	Ours lower	If a finding was closed, re-opened, and closed again within 90 days, Asana’s chart counts both completion events; we count once per `vortexiq_finding_id`. The duplicate-suppression makes our rate slightly lower if your team has a habit of re-opening.
Won’t Do treatment	Same	Both Asana’s `Tasks completed` chart and our card count `completed = true` regardless of whether the resolution was “Done” or “Won’t Do”.
Archived projects	Ours lower	Asana Reporting can include archived projects; we exclude them. Confirm filter parity.
Sub-task creation	Ours lower	Asana’s chart counts sub-tasks separately if the chart query includes sub-tasks; we count parent tasks only because that is where the `vortexiq_finding_id` lives.
Cross-workspace aggregation	Ours wider	Asana Reporting scopes to one workspace; we sum across all connected workspaces.

Cross-connector reconciliation. Asana resolution rate vs operations-health peers:

Card	Expected relationship	What causes the divergence
`datadog.dd_health_score`	Independent. Datadog Health is server-side production health; Asana resolution rate is internal team operations. They reflect different layers of the same merchant.	A high Datadog Health Score with a low Asana resolution rate means production is fine but the team is falling behind on the work that prevents future regressions. The cause-and-effect lag is typically 2-6 weeks.
`newrelic.nr_apdex`	Same shape as Datadog comparison.	Same lag.

Known limitations / merchant FAQs

My Asana Reporting chart shows 71% completed but you say 63%. What’s wrong? Eight points of gap is normal. The usual reasons in order: (1) Re-opened tasks: Asana counts each completion event, we count once per finding-id. If your team frequently re-opens, our number is the more conservative one. (2) Cross-workspace aggregation: we sum across multiple workspaces; check whether Asana’s chart was filtered to one workspace. (3) Window-rolling timezone (UTC vs profile-timezone). Open the per-workspace stack panel and the gap usually closes to within 2-3 points. Does “Won’t Do” count as resolved? Yes. From the audit programme’s perspective, both decisions are resolutions: the team chose to close the loop. If you want to track them separately, see the upcoming Won’t Do Rate card on the backlog. We treat them as identical here because over-counting “Won’t Do” closures (e.g. only counting “Done” status) discourages teams from cleanly closing low-value findings, which is the worst outcome. Our rate sits at 45%. Should I be concerned? Yes. Below 50% is the alarm threshold for a reason: the open queue compounds week-over-week and abandonment rate climbs in the following weeks. The standard playbook is the four-card investigation: open this card, Findings Open, Abandoned Findings, and Tickets by Assignee side-by-side. Within 5 minutes you’ll know if it’s a single-assignee bottleneck (most common), a sprint-planning bottleneck, or a calibration issue with the audit programme. We use multiple Asana workspaces. Which workspace’s rate matters most? The one with the lowest rate is the leading indicator. Open the per-workspace stack panel from the connector drawer to see them broken out. Marketing-led workspaces typically run lower than engineering-led ones; if your marketing-ops workspace sits at 50% while your site-reliability workspace sits at 90%, that’s normal and not actionable on its own. Task velocity dropped this week, rate is still high. What’s happening? This is the “team closed everything easy and left the hard stuff” pattern. Open Avg Time-to-Fix, if mean cycle time climbed alongside the velocity drop, the team has finished the quick-wins and is now starting on the heavier findings. This is a healthy phase that lasts 1-3 weeks; rate will dip during it then recover. Worry only if the dip lasts longer. Today’s rate looks volatile. Why? At low resolution volumes the rate is sensitive: 5 resolutions out of 8 is 62.5% and one extra close moves it to 75%. The 90-day window makes daily volatility small but visible. The 7-day moving rate (shown on the trend line beneath the headline) is less noisy. Multi-team reporting: how do I see resolution rate by team within one workspace? Asana’s team_gid is exposed in the API. The per-team stack panel is on the roadmap; until then, the workaround is to use one Asana project per team, tag each project as a separate vortex_iq_outbound route in connector setup, and the per-project stack will reflect per-team breakdown. Is Asana the right tool for tracking this metric? For ecommerce ops teams that span marketing, catalogue, CX, and engineering-light work, yes. Asana’s custom-fields + portfolios combination is uniquely suited to this use case. Engineering-only teams will find Linear’s velocity-and-cycle-time machinery more native. Visual-first teams will find Monday’s board view easier to scan. ClickUp’s strength here is per-task time-tracking which we don’t currently consume; Trello’s strength is its lightness which makes it under-equipped for this metric. Basecamp’s project-room model lacks completion-event granularity, so its rate calculation is the noisiest of the six. Resolution rate climbed but I don’t think the team did anything different. What changed? Three usual causes. (1) Audit programme produced fewer findings this period (denominator shrank, rate climbed). Check Findings Open trend. (2) A bulk closure of stale findings (e.g. the team did an “abandoned review” and closed 20 as Won’t Do). Check Asana’s audit log under Admin Console. (3) Project archiving: if a project was archived this week, all its open findings dropped out of the denominator while the resolved count stayed; this can lift rate by 5-10 points overnight.

Tracked live in Vortex IQ Nerve Centre

Finding Resolution Rate (90d) is one of hundreds of KPI pulses Vortex IQ tracks across Asana and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.

Get Started

The AI OS

Finding Resolution Rate (90d), Asana

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre

​At a glance

​Calculation

​Worked example

​Sibling cards merchants should reference together

​Reconciling against the vendor’s own dashboard

​Known limitations / merchant FAQs

​Tracked live in Vortex IQ Nerve Centre

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre