Findings sat in the backlog with no status change for two weeks, these are the ones losing money silently.
At a glance
Open Vortex IQ-tagged Jira issues with no field change in 14+ days. Jira is the dominant engineering-side PM tool for ecommerce merchants with dedicated engineering teams; the abandoned bucket here represents engineering-team-owned findings stuck in the backlog. On Jira-using merchants this card is the operational-discipline trip-wire; the parallel vortexiq_findings_open card sizes the queue, this card detects whether the queue is healthy.
Calculation
Calculated automatically from your Jira 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 UK 30-person ecommerce engineering team using Jira Software Cloud Premium. Single Jira site with three projects connected (ENG for engineering, OPS for operations, MKT for marketing tech). Snapshot taken on 02 May 26 at 11:20 BST.
- The ENG project has 8 abandoned findings, the largest cluster. Six are post-release debt from the 18 Apr release; the team shipped, moved to the next sprint, never came back to the audit-flagged regressions. The classic engineering-led abandonment pattern.
- The two ENG infra findings owned by the on-call rotation but unassigned individually. Jira’s “owner = team” without a single assignee is the silent-leak design pattern; nobody owns it personally so nobody picks it up. Fix: add a Jira automation rule that assigns rotation-owned findings to the current on-call individual via the Atlassian Opsgenie integration.
- The OPS project’s 3 abandoned findings have a single root cause. All three sit on a single ops lead on PTO. The fix is reassignment, not hiring. Open Jira’s Issues, Group by Assignee and confirm.
- The MKT marketing-team finding is normal latency, not abandonment. Marketing-team findings often wait for sprint planning at the start of each sprint cycle; the 14-day clock crosses sprint boundaries on slower-cadence teams. Tune the threshold for marketing-team subprojects to 21 days if this becomes a recurring pattern.
- The Returns-policy and refund-flow findings on OPS are highest-revenue-risk. Returns-policy mismatches are conversion killers; refund-flow regressions drive both refund rate and customer-service load. Triage these first regardless of count.
- Use Jira Automation to auto-flag abandoned findings. Build a rule:
Trigger: scheduled (daily at 09:00) IF (labels CONTAINS 'vortex_iq_finding' AND resolution = EMPTY AND updated < -14d) THEN add comment '@assignee This finding has not moved in 14+ days. Triage today or mark Won't Fix.' AND apply label 'abandoned'. Most engineering teams who adopt this see abandoned-bucket size drop 40 to 60% within a month.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Jira’s own dashboard:
Jira Issue Search with JQL: labels = "vortex_iq_finding" AND resolution = EMPTY AND updated < -14d ORDER BY updated ASC. Save as a filter via Save as; pin it to the team’s Jira dashboard.
Jira Dashboard build a gadget showing the saved filter’s count; the team sees the abandoned bucket inline with their normal Jira rhythm.
Atlassian Analytics (Premium / Enterprise tier) can build a chart of abandoned-bucket size over time using the same JQL.
Why our number may legitimately differ from the saved Jira filter:
Cross-connector reconciliation:
Known limitations / merchant FAQs
My Jira filter says I have 14 abandoned but the card says 12. Which is right? Almost always one of these. (1) Cross-project scope: the card aggregates across allvortex_iq_outbound projects; your filter may scope to one. (2) Resolution-field semantics: the card requires resolution IS EMPTY; if your filter uses status names directly (e.g. status NOT IN (Done, "Won't Fix")) and a workflow misconfiguration lets a status reach Done without setting the resolution field, your filter and the card diverge. (3) Webhook delay or API rate-limit lag during peak hours.
A Jira issue is in the “Done” column but my abandoned card still counts it. Why?
Workflow misconfiguration. The “Done” column on a kanban board is a visual grouping; what closes an issue from JQL’s perspective is the resolution field being non-empty. If your workflow lets a status reach the Done column without setting the resolution field, the issue is logically still unresolved. Audit Project Settings, Workflows; ensure every status that lands in the Done column has a transition that sets resolution. Atlassian’s documentation calls this the “Done resolution gap” and it is the most common cause of inflated abandoned counts.
What counts as movement?
Any of: status transition, assignee change, priority change, fix-version change, comment added, custom-field edit, sub-task added, attachment added, link added. Renaming the issue or editing the description also counts. Atlassian Intelligence accepted suggestions count (they update updated); unaccepted suggestions do not.
The 14-day window feels arbitrary. Can we tune it?
Yes, in Settings, Connectors, Jira, Abandonment threshold (days). Default is 14 days. Engineering teams running 2-week sprints often tune this down to 7 days because their cycle time is faster; teams running 4-week sprints tune up to 21 days because their planning cadence is slower.
We have multiple Jira projects connected. The count looks alarming.
Open the per-project stack panel from the connector drawer to see which project drives the abandoned count. Most multi-project merchants find the abandoned bucket concentrates in one or two projects (typically the lowest-priority project that gets de-prioritised under sprint pressure).
Velocity dropped, abandoned count rising. What changed?
Standard playbook. (1) Open Sprint Velocity; if velocity dropped, the team is being interrupted or under-staffed. (2) Open Issues by Assignee for sudden concentration changes; a key person on PTO is the most common cause. (3) Cross-check Datadog incidents; a sustained incident burst pulls the team off audit work for days. (4) Check whether sprint planning includes Vortex IQ findings; if findings are routinely deferred to “next sprint”, they accumulate.
The abandoned count appears suddenly higher overnight. Why?
Because the 14-day clock keeps ticking. 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. Normal and self-corrects 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 engineering lead. For each: if no real merchant impact, transition to Won't Fix with a comment explaining why. If real merchant impact, reassign and add to next sprint. We see Jira-using teams close 30 to 50% of abandoned findings on this triage as Won't Fix (out-of-scope, duplicate, no-longer-relevant); the remainder being correctly prioritised into a sprint is the win.
Can Jira Automation auto-flag or auto-close abandoned findings?
Yes. (1) Auto-flag: build a rule that comments @assignee This finding has not moved in 14+ days. Triage today or mark Won't Fix. on any matching issue, daily at 09:00. (2) Auto-close low-impact: build a rule that transitions any matching issue with priority Low or Lowest to Won't Fix after 21 days no-movement, with a comment explaining the auto-close. Most engineering teams who adopt these rules see abandoned-bucket size drop 40 to 60% within a month with no manual triage.
Why doesn’t Jira ship an “abandoned” filter natively?
Jira ships the JQL primitives (updated < -14d, labels CONTAINS X, resolution = EMPTY) but not the curated view. The card’s added value: cross-project aggregation, threshold-based alerts, historical trend, and cross-connector reconciliation. Engineering teams comfortable with JQL can build the saved filter themselves.
A finding important enough to fix manually but we never used Jira to track it. Do we close the ticket?
Yes. Transition the issue to Done (with a Done resolution) once the work is shipped, or Won't Fix if the audit signal is no longer relevant. Otherwise it stays in the abandoned bucket. Vortex IQ does not auto-close findings just because the underlying audit signal cleared; the human acknowledgement is the close signal.
Can Atlassian Intelligence help me clear the abandoned bucket?
Partially. AI can suggest summaries, status changes, and assignees on individual issues; accepted suggestions count as movement and reset the abandonment clock. AI cannot triage the bucket as a whole. The combination that works: open the saved abandoned filter, walk through 5 to 10 issues, accept AI suggestions where reasonable, manually triage the rest. Reduces a 30-minute weekly review to 10 to 15 minutes.
Multi-site Jira: my company has US and EU Jira sites. Does the card aggregate?
Yes by default if both are connected. Multi-site is rare; most ecommerce merchants run one Jira site with multiple projects. If your sites are genuinely separate (e.g. acquired company kept its own Jira), configure two connectors for per-site cards.
Is this card the right primary watch metric for Jira-using merchants?
Yes. Findings Open tells you the queue size; this card tells you the queue health. Both are hero cards because they answer different questions. On engineering-led merchants using Jira, the abandoned card is the single best signal of audit-programme health because Jira backlogs naturally grow over time; the abandoned subset is what flags execution-discipline regressions.