At a glance
Of every audit finding that landed on the Miro board in the last 90 days, the percentage that has been moved to the Done column. The headline number for “is the audit-board actually working as a delivery surface, or is it just collecting dust?” Pair it with the open count to grade the team’s flow: high open + low resolution rate is a queue forming; low open + high resolution rate is healthy clearance.
| What it formula | (findings closed in last 90D) / (findings created in last 90D) × 100. Closures use the timestamp the card entered the rightmost (Done) column. Creations use the original card-creation timestamp on the configured Miro board. |
| Why a 90-day window | Smooths out workshop-week spikes (where many cards are added at once and take 2-4 weeks to clear). A 30-day window swings wildly week-to-week; 90 days captures both the intake and the exit cycles fairly. |
| Numerator (resolved) | Count of cards tagged vortexiq:finding that moved into the Done column in the trailing 90 days. Re-opened cards do NOT decrement this; if a regression card is moved Done → In progress → Done, both transitions count once each. |
| Denominator (created) | Count of cards tagged vortexiq:finding that were created on the board in the trailing 90 days. Cards on the board before the 90-day window are excluded from BOTH numerator and denominator (so the ratio is clean). |
| Edge case, zero creations | If no findings were created in the window the card displays -- rather than 100% or 0%, both of which would be misleading. |
| Threshold rationale | Good ≥75%, warn 50-75%, critical <50%. Empirically a healthy audit programme closes 70-85% of findings within 90 days; 50% is the line where the team is creating findings faster than they can resolve them. |
| Time window | 90D (rolling) |
| Alert trigger | <50% |
| Sentiment key | vortexiq_finding_resolution_rate, gauge-typed (good ≥75, warn ≥50) |
| Roles | owner, operations |
Calculation
Calculated automatically from your Miro 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 fashion brand on Shopify has the Miro audit-board running for 4 months. Snapshot taken on 02 May 26. Trailing 90 days: 03 Feb 26 → 02 May 26 (89 days).| Severity | Created | Resolved | Rate |
|---|---|---|---|
| critical | 9 | 9 | 100% |
| high | 18 | 16 | 89% |
| medium | 22 | 14 | 64% |
| low | 15 | 8 | 53% |
Sibling cards merchants should reference together
| Card | Why pair it with Resolution Rate | What the combination tells you |
|---|---|---|
| VortexIQ Findings Open | The numerator’s complement. Open is the queue at this instant; resolution rate is the long-window flow. | Open rising + rate falling = compounding backlog. Open falling + rate rising = team caught up. |
| Abandoned Findings (>14d no movement) | Abandoned is the leading indicator of a falling resolution rate. | Abandoned rising for 2-3 weeks reliably foreshadows a rate drop in the next 30-60 days. |
| Avg Time-to-Fix (days) | Cycle time on the resolved subset. The “how fast” peer to “how many”. | Rate at 80% with avg time-to-fix at 21 days = team gets there but slowly. Rate at 80% with time-to-fix at 5 days = fast and clean. |
| Throughput Trend (30d) | The weekly closure rhythm; multiplied by 12-13 weeks should approximate the resolution rate’s numerator. | Numerator from rate / weekly throughput = number of weeks tracked. Sanity check the maths. |
| Datadog Operational Health Score | If the Datadog health score is dropping while resolution rate is dropping, the team is seeing more findings AND fixing fewer of them. | Worst-case combination, escalate. |
| Jira Finding Resolution Rate | Jira-side equivalent for teams that mix tools. Often the canonical number for engineering-led work. | Jira rate higher than Miro rate is normal (Jira tickets are higher-discipline); the gap tells you how much culture difference there is between the two surfaces. |
Reconciling against the vendor’s own dashboard
Where to look in Miro’s own dashboard: Miro does not provide a native flow / cycle-time dashboard. The closest manual reconciliation is to filter the board by tag and inspect creation vs. last-modified dates over the last 90 days.Miro board → open the configured board → Tags panel →For most merchant teams the manual reconciliation is impractical (60+ cards with date filtering by hand), which is why this card exists. Why our number may legitimately differ from a manual count:vortexiq:finding→ Outline panel → sort bycreatedAtdescending → manually count cards in Done vs. cards not in Done across the trailing 90 days.
| Reason | Direction | Why |
|---|---|---|
| Re-opened cards | Ours higher | If a card was Done, then re-opened, then Done again, both transitions count. A merchant counting “cards currently in Done” by hand only counts the latest state. |
| Cards moved to Done by accident | Ours higher | A drag-and-drop into the wrong column with no reverse counts as a closure. The manual review may flag those as “not really done” and exclude them. |
| 90-day window edge | Boundary drift | Cards created on day 91 of the trailing window are excluded; cards created on day 89 are included. The window slides daily. |
| Polling cadence | Ours stale up to 60s | Same as the other Miro cards. Sub-minute closures lag in the rate. |
| Time zone | Boundary days off | The 90-day window is computed in UTC; merchants in PST may see day-1 / day-91 boundaries shift relative to their working calendar. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
jira.jir_vortexiq_finding_resolution_rate | Definitional twin on Jira. Same window, same formula. Where both are connected and dispatch to both, the two rates measure overlapping but not identical populations. | Jira rate typically higher (formal workflow, enforced statuses). Miro rate measures behaviour on a more permissive surface; the gap tells you how much “real” work happens off the formal tracker. |
mural.mur_vortexiq_finding_resolution_rate | Same metric on Mural. Mural’s facilitation-led workshops can spike the denominator on workshop weeks. | Expect lower rate during workshop-heavy quarters, higher during steady-state quarters. |
asana.asa_vortexiq_finding_resolution_rate | Same metric on Asana, the lightweight-PM peer. | Asana rates often run higher than Miro because Asana enforces task ownership; Miro is more democratic and therefore looser on closure discipline. |
Known limitations / merchant FAQs
Why is my rate stuck at exactly 100%? Three possibilities: (1) you have very few findings (e.g. 3 created in 90 days, 3 resolved); the rate looks great but the window is too thin to be meaningful, look at the absolute count of resolved findings instead. (2) Auto-dispatch is misconfigured and findings are not reaching the board; the denominator is artificially small. (3) The team is closing cards on creation as a workflow, which defeats the point of the audit-board. Check intake volume against the Throughput Trend sibling. Why is my rate exactly 0%? Either no closures in 90 days (the team has not engaged with the board) or the team uses a custom Done-state Vortex IQ does not recognise. Check the connector’sdone_column_id setting; the connector defaults to “rightmost column” but a hidden / collapsed column to the right can throw it off.
Does a re-opened card hurt my rate?
No. Re-opening does not subtract from the numerator; only forward closures count. Re-opening a card adds to the open count (which surfaces on Findings Open) but does not penalise this card. The reasoning: regressions are a separate phenomenon from closure discipline, and double-counting punishes the team unfairly when they correctly catch a regression.
The rate dropped from 80% to 65% but no individual finding changed status. What happened?
Window-edge effects. The 90-day window is rolling, so cards aged into the window or aged out of it. Specifically: if a closure happened on day 91 (just outside the window now) and a creation was on day 90 (just inside), the rate would drop without any active behaviour change. This is normal noise; look at week-over-week change rather than day-over-day.
Should I optimise this number directly?
No. Resolution rate is a downstream indicator, not a target. Optimising it directly leads to bad behaviour: closing cards without fixing the underlying issue, or refusing intake to keep the ratio healthy. Optimise throughput (more closures) and abandonment (fewer ignored cards) and the rate follows. Treating the rate as a target produces the dashboard equivalent of teaching to the test.
Why 90 days, not quarterly?
A rolling 90-day window updates daily; a quarterly window resets every 90 days and creates artificial cliffs. Rolling is fairer for spotting trends and avoids “end-of-quarter scramble” gaming. Practically, 90 days ≈ a quarter for benchmarking purposes.
My team uses Miro for ideation, not delivery. The findings are mostly low-priority brainstorm outputs. Does this card make sense?
Probably not, in that configuration. The audit-board pattern assumes the board is being USED as a delivery surface (cards represent committed work). If your Miro is a discovery whiteboard, the resolution rate is misleading because most cards are not meant to be “done” in the operational sense. In that case, route audit findings to a different surface (Jira, Linear, Asana) and keep Miro for ideation. The audit-routing settings let you turn off the Miro target while keeping Miro connected for other read-side cards.
A workshop generated 30 cards last week. They will all be tagged vortexiq:finding because the auto-tagger applied. Will my rate plummet?
Yes, in the short term. The 30 cards lift the denominator immediately; the closures lag by weeks. Expect the rate to drop 10-20 points within a week, recover over 4-8 weeks as closures catch up. The 90-day window is calibrated to absorb this kind of spike without false alerting in most cases. If the team runs many workshops, consider tagging workshop output with vortexiq:reference instead so it is excluded from the rate.
How does Vortex IQ know a card was created on the board “in the last 90 days”?
The Miro REST API exposes createdAt per item; the connector polls and persists this. The 90-day window is calculated against the current UTC time at request. If the connector was reconnected mid-window, only cards created since the connector’s first sync are guaranteed to be in the denominator (cards from before the reconnect may be missing if the original sync was incomplete).