Tickets we created from audit findings that haven’t been resolved yet.
At a glance
The live count of work-items VortexIQ created on your Miro board for audit findings that nobody has marked done yet. This is the “are we actually fixing the things our audits surface?” number for teams that run their delivery on a Miro Kanban frame instead of a formal tracker. Unlike Jira (where Atlassian gives us a proper ticket model), Miro work-items are sticky-notes-with-metadata, so the definition of “open” leans on convention more than enforced workflow.
| What it counts | Sticky notes / cards on the configured Miro board where the VortexIQ-finding tag is present and the status column is anything other than the team’s “done” column. Each finding maps 1:1 to one Miro item; duplicates are de-duplicated on the vortexiqFindingId custom field. |
| Board / frame scope | The single Miro board configured on the connector (one board per Miro connection). Cross-board roll-ups need a parent connection in Vortex IQ; we do not pull sibling boards from the same Miro team. |
| Status filter | ”Open” means anything not in the rightmost column of the board. We rely on column position because Miro has no native status enum. If your team renames the rightmost column from “Done” to “Shipped” or “Closed” the count still works, the position is what matters. |
| Item type filter | All Miro item types where the VortexIQ tag is present (sticky notes, cards, and shapes-with-tags). Connector lines and free-form text are ignored. |
| Resolution counts | A finding leaves the count when someone moves the item into the rightmost column or deletes it. Archiving a frame does NOT clear the count by default; archived frames are still polled. |
| Time window | RT (Miro REST API polled every 60 seconds; the count is a live snapshot, not a trend). |
| Alert trigger | >20 open, calibrated against typical merchant audit cadence (Vortex IQ surfaces 5-15 findings per audit run; >20 standing means the team is detecting faster than they are fixing). |
| 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 home-and-garden brand on Shopify runs their ops backlog on a single Miro board called Storefront ops 26. The board has four columns: Inbox, In progress, Review, Done. Vortex IQ creates one Miro card per audit finding and tags itvortexiq:finding.
Snapshot taken on 02 May 26 at 09:30 BST:
| Column | Cards tagged vortexiq:finding |
|---|---|
| Inbox | 14 |
| In progress | 5 |
| Review | 3 |
| Done | 41 |
- 9 of the 14 Inbox cards are tagged
severity:critical(mostly checkout-script errors flagged by Datadog last week). - 5 of the In progress cards have been sitting there for more than 14 days with no movement, which is the abandonment threshold the next card down (Abandoned Findings) tracks.
- 3 in Review are with the developer pending QA.
Sibling cards merchants should reference together
| Card | Why pair it with VortexIQ Findings Open | What the combination tells you |
|---|---|---|
| Abandoned Findings (>14d no movement) | Of the open count, how many have been ignored. The “stuck” subset of the queue. | Open rising and Abandoned rising together is a capacity problem; Open rising while Abandoned is flat means the team is still triaging actively. |
| Finding Resolution Rate (90d) | The flow ratio. Are findings entering or exiting faster? | Open count above 20 with resolution rate below 50% means the backlog will keep growing without a process change. |
| Throughput Trend | The 30-day closure rhythm. Compare the open snapshot against weekly throughput. | Open / weekly throughput tells you backlog age in weeks. 20 open at 5/week throughput equals four weeks of work standing. |
| VortexIQ Findings Resolved (90d) | The completion peer. Same population, opposite end of the funnel. | Open + Resolved = total findings created. Use the ratio to grade the audit programme’s actionability. |
| Datadog VortexIQ Findings Open | If the team also runs Datadog audits, both connectors push findings into Miro. | Cross-source findings concentrate on the same fix, dedupe before triaging. |
| Critical Findings Without a Jira Ticket | Coverage-gap peer for teams that mix Miro and Jira. | If criticals appear here that should be in Jira, the auto-dispatch routing is misconfigured. |
Reconciling against the vendor’s own dashboard
Where to look in Miro’s own dashboard: Miro does not provide a native “open work-items” dashboard, the platform is a canvas, not a tracker. The closest reconciliation is to open the configured board, filter cards by tag (vortexiq:finding), and count the cards in any column other than the rightmost “Done” column.
Miro board → open the board configured on the connector → click the magnifying-glass icon (top-right) → search tag:vortexiq:finding → count cards visible outside the rightmost column.
If the team uses Miro’s Tags panel (left sidebar), filter by vortexiq:finding and the canvas highlights every matching card; the visual count should match this number exactly.
Why our number may legitimately differ from a manual board count:
| Reason | Direction | Why |
|---|---|---|
| Polling cadence | Ours stale up to 60s | Miro REST API is polled every 60 seconds. A card moved into Done in the last minute may still appear open here. |
| Frame archival | Ours higher | Archiving a frame in Miro hides it from the canvas but does NOT delete the cards. Vortex IQ still polls archived-frame contents unless the connector is configured to skip them (exclude_archived: true). |
| Hidden columns | Ours higher | Cards moved into a hidden / collapsed column still count as “not in the rightmost column” and therefore still open. |
| Custom field mapping | Possible mismatch | If the team renamed the vortexiqFindingId custom field on the board, the de-duplication breaks until the connector mapping is re-synced. |
| Multiple boards in one Miro team | Manual count higher | Vortex IQ counts only the configured board. A merchant manually browsing the Miro team may include cards from sibling boards in their mental tally. |
| Time zone | None | This is a real-time count with no period boundary, so time-zone drift does not apply. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
jira.jir_vortexiq_findings_open | Definitional twin if both connectors are connected. The same audit finding can dispatch to Jira AND Miro simultaneously when both are configured as routing targets. | A finding shows on Miro only when the merchant set Miro as a target in the audit-routing settings; otherwise Jira is canonical. Treat Miro as the team’s working surface, Jira as the system of record. |
mural.mur_vortexiq_findings_open | Same metric on the Mural connector. | Teams generally pick one whiteboarding tool, so seeing both populated implies a migration is in progress; reconcile by checking which board is the active source-of-truth. |
lucidchart.luc_vortexiq_findings_open | Same metric on Lucidchart. | Lucidchart is documentation-first rather than triage-first; Lucidchart-as-tracker is uncommon, expect divergent populations. |
Known limitations / merchant FAQs
My Miro board has a “Backlog” column on the far left and “Done” on the far right. The card counts everything except Done as open. Is that correct? Yes. The connector treats column position as the status proxy because Miro has no native status enum. Anything that is not in the rightmost column is “not yet finished”. This is what the merchant intends in 95% of cases, but if your team uses a non-standard layout (e.g. Done in the middle, with a “Validated” column to the right), reconfigure the connector’sdone_column_id setting to point at the right column.
Why does Vortex IQ use Miro at all? Why not Jira for everything?
Two reasons. First, smaller teams (under 10 people) often skip Jira because the licence cost outweighs the value, but they still need somewhere visual to track audit findings, Miro fills that role. Second, design-led brands (DTC fashion, hospitality, gifting) tend to live on Miro and resist using Jira for non-engineering work. Pushing audit findings into the tool the team already uses every day raises the chance they get fixed.
The count never goes to zero, even after we’ve cleared the board. Why?
Three usual causes: (1) An archived frame still has tagged cards in it, archived frames are still polled by default; toggle exclude_archived: true in the connector config to fix; (2) A card was deleted but Miro’s API has a 5-15 minute eventual-consistency lag on deletions; (3) The Miro user who deleted the cards did not have permission to remove the vortexiq:finding tag, so the cards still match the filter even though the visible content is gone.
Can I move a card back from Done if we found a regression?
Yes, that is the natural Miro flow. Drag the card back into “In progress”, and within 60 seconds the open count increments. The vortexiq:reopened tag is auto-applied so the abandonment-clock resets to zero (so a regression does not immediately show up as Abandoned even though the original card is technically old).
A teammate added a card with the vortexiq:finding tag manually. Will it count?
Yes. The tag is the filter. If a teammate adds the tag manually, Vortex IQ treats it as if the auto-dispatcher created it. This is by design, the team can promote any finding into VortexIQ tracking. The downside is that manual additions do not get a vortexiqFindingId custom field, so they are not de-duplicated against the audit feed (and can show as duplicates if the auto-dispatcher later creates a finding for the same issue).
Why does this card matter to a non-engineering merchant?
Because Miro is where the visible delivery work lives for design-led teams. If the open count on Miro is rising, your design / front-of-house team is collecting more issues than they are clearing, which over weeks shows up as “the site keeps having small bugs that nobody seems to fix”. This card is the early-warning version of that complaint, surfaced before the merchant has to notice it manually.
Should this number ever be zero?
No, and aiming for zero is wrong. A healthy Miro audit-board has 5-15 standing items at any moment, that is the normal cadence of audit detection vs. team capacity. Zero usually means the auto-dispatcher is misconfigured (findings not being routed) or the team is bypassing the board entirely (fixing without tracking).