Findings sat in the backlog with no status change for two weeks, these are the ones losing money silently.
At a glance
The number of open VortexIQ findings in Asana whose status, section, or assignee has not changed in 14+ days. These are the items the team meant to fix but didn’t, the silent revenue leaks that quietly compound. A high count usually correlates with a regression in operational discipline (post-launch rush, a holiday lull, an unfilled ops role) before it shows up in commerce KPIs.
| What it counts | Open Asana tasks with vortexiq_finding_id set AND completed = false AND modified_at older than 14 days. The 14-day window is fixed; tunable per organization in connector settings. |
| API endpoint | GET /tasks?project={gid}&completed_since=now&modified_since={now-14d}&opt_fields=modified_at,completed,custom_fields, with the inverse condition applied client-side because Asana’s API filters by modified_since (newer than) not modified_until. |
| What counts as “movement” | Any of: assignee change, section move, status custom-field change, comment posted, due-date change, or completion. We read Asana’s modified_at which is updated on any of these. |
| Closed tasks excluded | Yes, the moment Asana’s webhook fires the completion event. |
| Archived projects | Excluded. Archived projects do not contribute regardless of task age. |
| Project / workspace scope | All projects tagged vortex_iq_outbound across all connected Asana workspaces. |
| Time window | RT. The 14-day staleness clock is rolling, evaluated on every webhook event and on a 5-minute scheduled refresh as a safety net. |
| Alert trigger | > 5 (warn), > 15 (critical). The warn threshold catches early stagnation; the critical threshold reflects systemic execution failure (more than 15 findings going stale in 14 days means the audit programme is generating work the team cannot absorb). |
| Sentiment | Threshold-based, {warn: 5, critical: 15}. |
| Time zone | modified_at is ISO-8601 UTC. Vortex IQ aligns the 14-day cutoff to UTC, so a task last touched at 23:55 UTC on day 0 becomes abandoned at 23:55 UTC on day 14, regardless of the merchant’s local timezone. |
| Multi-workspace aggregation | Yes by default; a per-workspace stack panel is 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 mid-market homewares brand running Adobe Commerce and Klaviyo, 24-person team. Marketing operations runs Asana. Snapshot taken on 02 May 26 at 14:00 BST.| Asana project | Open findings | Abandoned (>14d no movement) | Notes |
|---|---|---|---|
| Marketing Operations | 19 | 7 | Mostly meta/og-image findings from the Easter campaign (now 17 days untouched). |
| Catalogue & Merchandising | 12 | 5 | Five missing-structured-data findings on the new “Outdoor Living” category, untouched since the catalogue lead went on parental leave. |
| Site Reliability | 8 | 1 | Healthy; engineering closed most within a sprint. |
| CX & Returns | 6 | 2 | Two returns-policy URL-drift findings flagged 18 days ago. |
| Total open | 45 | 15 | At critical threshold. |
- Status hit critical. 15 findings going 14+ days without movement is the systemic-execution-failure pattern. This is the card to escalate, not the headline open count.
- The catalogue cluster has a single root cause. Five findings stagnant since the catalogue lead went on leave. The fix is not “close the findings”, it is “reassign the queue today”. Open Tickets by Assignee to confirm.
- The marketing cluster is post-launch debt. Seven Easter-campaign findings stagnant for 17 days is the classic “we shipped the campaign and never went back to clean up the meta tags” pattern. These map directly to organic-traffic regressions; pair with Google Search Console crawled-but-not-indexed counts to quantify the SEO impact.
- Returns-policy drift left unfixed for 18 days is the highest-revenue-risk item on the list. Returns-policy mismatches are a known conversion killer; this single cluster is likely costing more revenue than the other 13 abandoned items combined.
- The right action is a triage meeting, not a hire. Assign one ops lead to walk the abandoned list weekly, mark anything with no real merchant impact as
Won't Do(which closes it cleanly), and re-prioritise the rest into next sprint. Most merchants find 30-50% of abandoned findings should be closed-not-fixed; doing this triage once a week stops the queue compounding.
Sibling cards merchants should reference together
| Card | Why pair it with Abandoned Findings | What the combination tells you |
|---|---|---|
| VortexIQ Findings Open | Abandoned is a subset of open. The ratio is the steadier read. | Abandoned ÷ Open above 30% means a third of the queue has gone dormant. |
| Finding Resolution Rate (90d) | Resolution rate drops first; abandoned count rises second. | Resolution falling for two weeks then abandoned spiking is the textbook capacity-collapse sequence. |
| Avg Time-to-Fix (days) | Distinguishes “slow but moving” from “abandoned”. | Time-to-fix rising AND abandoned rising means the team is starting then stalling, not refusing the work. |
| Tickets by Assignee | Tells you whether abandonment concentrates on one person. | If 70% of abandoned findings sit on one assignee, the fix is reassignment, not hiring. |
| Overloaded Assignees (>10 open) | Same person often appears on both. | An overloaded assignee with several abandoned items needs an immediate queue review. |
| Sprint Progress | Findings that never enter a sprint are the ones that abandon. | Low sprint progress + high abandoned = findings being created but never planned in. |
| Scope Added Mid-Sprint | Mid-sprint scope creep crowds out audit findings first. | High scope creep + rising abandoned = the team is reactive, not proactive. |
Reconciling against the vendor’s own dashboard
Where to look in Asana’s own UI:app.asana.com then open eachWhy our number may legitimately differ from a saved Asana filter:vortex_iq_outboundproject. In List view, click Filter, addCustom Fields → vortexiq_finding_id → is set,Completion → Incomplete, andLast modified → More than 14 days ago. Asana does not have a single “abandoned” view, so this card is closest to a saved filter you build yourself. Save it via Save view as for repeat use.
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary day off | Vortex IQ aligns the 14-day cutoff to UTC; Asana’s UI uses your account-profile timezone. A task last touched at 23:55 UTC on day 0 becomes abandoned at 23:55 UTC on day 14 in our view, which may be a different calendar day in your local UI. |
| Archived projects | Ours lower | Asana’s filters can include archived projects; we exclude them. Confirm “Include archived” is unchecked in Asana to match. |
| Custom-field deletion | Ours lower | If vortexiq_finding_id is cleared from a stale task, the task drops out of our count even though it is still abandoned in operational reality. |
| Cross-workspace aggregation | Ours typically higher | Asana scopes to one workspace; we sum across all connected workspaces. |
| Sub-task counting | Ours lower | Vortex IQ creates findings as parent tasks. If a teammate adds untouched sub-tasks beneath, those sub-tasks are not separately counted; only the parent. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
datadog.dd_incidents_active | Independent. A live Datadog incident is a paging-grade engineering signal; an abandoned Asana finding is an organisational-discipline signal. | A growing Datadog incident count alongside a growing Asana abandoned count is the compound signal that engineering is firefighting and ops is falling behind simultaneously. |
newrelic.nr_open_incidents | Same shape as Datadog comparison. | Same reasoning. |
Known limitations / merchant FAQs
Asana shows my finding was modified yesterday but you say it’s abandoned. What’s wrong? Almost always one of two things. (1) The “modification” was Asana’s automatic re-index after a workspace-admin change (e.g. someone restored a custom field), which we do not treat as task movement; we readmodified_at directly and that field will reflect the re-index. Open the task and check the activity feed, if there’s no human-action entry in the last 14 days, our count is correct. (2) Webhook delay: an edit made in the last 5 minutes may not have reached us yet; refresh in 5 minutes.
What counts as movement?
Any of: assignee change, section move, status custom-field change, comment posted, due-date change, or completion. Renaming the task or editing the description also counts. What does NOT count: someone just opening the task to read it (Asana does not surface “viewed” events). Following or unfollowing the task does not count either.
The 14-day window feels arbitrary. Can we tune it?
Yes, in Settings → Connectors → Asana → Abandonment threshold (days). We default to 14 days because it sits one full sprint plus a buffer, which empirically separates “in active backlog” from “forgotten”. Engineering-led teams using Linear often tune this down to 7 days; agency-led teams using Monday sometimes tune it up to 21 days because their work cycles are longer.
We have multiple Asana workspaces. The count looks alarming.
Open the per-workspace stack panel from the connector drawer to see which workspace is driving the abandoned count. In our experience, multi-workspace merchants typically find one workspace (often the marketing-ops one) drives most of the abandoned count while the engineering-ops workspace stays clean.
Task velocity dropped, abandoned count rising. What changed?
Standard playbook: (1) Open Tickets by Assignee and look for sudden concentration changes; a key person leaving or going on leave is the single most common cause. (2) Open Sprint Progress; if velocity dropped because findings stopped entering sprints, the bottleneck is the planning meeting, not the team. (3) Open Scope Added Mid-Sprint; if scope creep climbed in parallel, the team is being interrupted out of audit work. (4) Cross-check against Datadog incidents; a sustained incident burst pulls the team off audit work for days at a time. The combination of these four cards usually identifies the cause within minutes.
The abandoned count appears suddenly higher overnight, even though no one was working. Why?
Because the 14-day clock keeps ticking even when no one is editing. If five findings were last touched on the same day exactly 14 days ago, all five become abandoned at the same time the next day. This is normal and corrects itself within 24 hours of the team picking the queue back up.
Should I close abandoned findings or fix them?
Both, depending on triage. Run a weekly 30-minute “abandoned review” with one ops lead. For each: if no real merchant impact, mark as Won't Do (which closes the task cleanly). If real merchant impact, reassign and put in next sprint. We see merchants close 30-50% of abandoned findings on this triage; the remainder being correctly prioritised is the actual win, not the count itself.
Is this the right card for my context, or should I focus on Findings Open?
Findings Open tells you the queue size; this card tells you the queue health. Use Findings Open to size the team’s workload. Use this card to detect execution discipline regressions. Both are hero cards because they answer different questions; if you only watch one, watch this one, the open count can climb for healthy reasons (audit found more this week) but a rising abandoned count is rarely benign.
Why doesn’t Asana have a built-in “abandoned” filter?
Asana’s data model treats all open tasks as equal until something explicit happens. The “abandoned” concept is a Vortex IQ overlay; we apply it because operational discipline is the metric merchants actually care about, even though Asana doesn’t surface it natively. The same applies to Trello, ClickUp, Monday, Linear, and Basecamp, none of them ship an abandoned-task primitive, all of them have task-modification timestamps we can read.