Tickets we created from audit findings that haven’t been resolved yet.
At a glance
Live count of pages or database rows Vortex IQ created in your Notion workspace from audit findings, that you haven’t moved into a “Done” status yet. This is your unworked-finding queue.
| What it counts | Notion items (pages or database rows) tagged vortexiq:finding whose Status property is not in your “done” set. Each open row counts as one. Sub-pages do not count separately unless they carry their own vortexiq:finding tag. |
| Project / board scope | The single Notion database the merchant maps to “Findings” during connector setup (Settings → Connectors → Notion → Findings database). Vortex IQ does not crawl the entire workspace, the database is named explicitly so we don’t accidentally count meeting notes or wikis. |
| Status filter | Open = any status not in the merchant-configured “done” group. Notion lets you define multiple status groups (To-do, In progress, Done); we treat Done as closed and everything else as open. If your status list uses custom names like “Shipped” or “Live”, map them to the Done group in Notion’s database settings. |
| Issue type filter | None applied at the API layer. The mapped database is assumed to hold findings only. If your team mixes findings with regular tasks in one database, add a Source select property and filter by Source = vortex_iq in the connector settings. |
| Database property scheme | Notion uses custom properties per database, there is no built-in “ticket” concept. The connector reads three properties by name: Status (status type), Priority (select), Assignee (people). Renaming any of these in Notion will break the read until you reconnect. |
| Resolution counts | Once a row’s Status moves to a Done-group value, it drops out of this count immediately on the next sync (typically within 60 seconds via Notion’s webhook). |
| Sync mechanism | Notion fires page.properties_updated webhooks; Vortex IQ also reconciles every 15 minutes via the databases.query REST endpoint to catch any webhook misses. |
| Time window | RT (real-time, latest sync). |
| Alert trigger | >20 open (the queue has grown faster than your team can work it). |
| Roles | owner, operations |
Calculation
Calculated automatically from your Notion 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 uses a Notion database called Site Improvements as their lightweight ticketing system (the team prefers Notion over Jira). Vortex IQ writes findings into this database. Snapshot taken on 12 Mar 26. The Site Improvements database has 47 rows taggedvortexiq:finding, with the following status distribution:
| Status (Notion property value) | Status group | Rows | Counts as open? |
|---|---|---|---|
| Not started | To-do | 18 | yes |
| In progress | In progress | 9 | yes |
| Waiting on dev | In progress | 4 | yes |
| Blocked, needs design | In progress | 2 | yes |
| Done | Done | 12 | no |
| Won’t fix | Done (mapped) | 2 | no |
>20). The merchant’s owner-dashboard banner reads “33 unworked Vortex IQ findings, queue grew by 8 this week”. The follow-up cards (Avg Time-to-Fix, Finding Resolution Rate) tell them whether the queue is growing because findings are arriving faster, or because the team is closing them slower.
Why the “Won’t fix” rows don’t count: during connector setup the merchant mapped the Notion Won’t fix status into the Done group, signalling “we’ve decided, stop counting it”. This is the recommended pattern, abandoning a finding closes it for KPI purposes; it does not delete the page.
Sibling cards merchants should reference together
Open Findings is a queue depth, not a verdict. Read it next to these:| Card | Why it matters next to Open Findings | What the combination tells you |
|---|---|---|
| Abandoned Findings (>14d no movement) | Open count includes everything not Done; abandoned isolates the rows nobody is touching. | If Abandoned is high relative to Open (say >30%), the queue isn’t busy, it’s stuck. Different fix. |
| Finding Resolution Rate (90d) | Tells you whether the team is keeping up with the inflow. | Open growing + resolution rate falling = the team is losing ground. Open growing + resolution rate stable = inflow surge. |
| Avg Time-to-Fix | Days from finding creation to Done. | High Open + low Time-to-Fix = healthy turnover, queue is just deep. High Open + high Time-to-Fix = capacity problem. |
| Tickets by Assignee | Shows whether the queue is concentrated on one person. | If 25 of 33 open findings sit with one assignee, that’s a routing problem, not a backlog problem. |
| Unassigned Tickets | Open findings without an Assignee people-property are invisible to anyone’s “My tasks” view in Notion. | A high unassigned share inside Open is the single biggest reason findings sit untouched. |
Reconciling against the vendor’s own dashboard
Where to look in Notion itself: Notion does not have a vendor “dashboard” the way Jira or Datadog do. The closest equivalent is a filtered view of your Findings database:Open the Findings database → click the view dropdown at the top → New view → Board (or Table) Filter:The row count at the bottom of that filtered view should match this card exactly (within the sync window, see below). Why our number may legitimately differ from your Notion view:Statusis notDone(or whichever group you mapped to closed). Group: byStatus. Optional: filterTagscontainsvortexiq:findingto exclude any rows the team added manually.
| Reason | Direction | Why |
|---|---|---|
| Sync lag | Ours lower | The card refreshes from webhook + 15-minute reconciliation. A finding closed in Notion 2 minutes ago may still appear in our count until the next sync tick. |
| Status mapping | Either | If you change the Done group in Notion (e.g. add a new status called “Live”) without re-mapping it during connector setup, our card and your view will diverge. Re-run Settings → Connectors → Notion → Refresh status mapping to align. |
| Permission scope | Ours higher | The Notion integration token Vortex IQ holds may have access to all rows; a teammate viewing the database in their browser sees only rows shared with them. Their count will be lower than ours; ours is the correct organisational total. |
| Trashed pages | Ours lower | Notion soft-deletes pages to Trash for 30 days. We exclude trashed rows immediately; the merchant’s “All” view includes them until cleared. |
| Multi-database setup | Ours lower | If the team accidentally creates a second findings database (e.g. on a sub-page) and our connector only points at the first, those rows are invisible to us but visible if you open the second database. Always keep findings in the one mapped database. |
Known limitations / merchant FAQs
Why is my Open count rising? Three usual reasons, in order of likelihood:- Inflow exceeds outflow. New findings keep arriving (audits, scheduled scans) but the team isn’t moving rows to Done at the same rate. Check Finding Resolution Rate (90d); if it’s below 60%, the team is genuinely behind. Add capacity, downgrade priority of low-value findings, or batch-close ones you’re not going to action.
- Status mapping drift. Someone added a new status value to the Notion database (e.g. “On hold”) that isn’t mapped to either To-do, In progress, or Done. Notion’s API still returns it, and we count it as open by default. Map it in Settings → Connectors → Notion → Status mapping.
- Findings going to the wrong database. If your team uses several Notion databases and a recent integration setup pointed Vortex IQ at the wrong one, you’ll see a confusing rise. Reconfigure the destination database in connector settings.
vortexiq:finding tag to any sub-page only if it’s genuinely a separate finding.
What if a teammate manually creates a row tagged vortexiq:finding?
It will count. The tag, not the creator, is the signal. This is intentional, it lets you migrate older findings into the system or hand-create a finding from a customer email and have it tracked alongside the auto-generated ones.
Why is “20 open” the alert threshold? Our team handles more than that comfortably.
The default is calibrated for a small ecommerce team (1, 5 people working on findings). Larger teams should raise it in Settings → Connectors → Notion → Alerts → Open findings threshold. The right number is roughly 2× your weekly resolution rate, e.g. if you typically close 15 findings per week, set the alert at 30, that’s two weeks of unworked queue.
Can the card distinguish between “untouched” and “in progress”?
Open is the rolled-up number. For the breakdown, look at Backlog by Status. The hero card stays a single number on purpose, you scan it in 1 second and decide whether to drill down.
My status names are in another language (French / German). Does it still work?
Yes. Notion’s status property uses internal status-group IDs (todo / in_progress / done), not the visible label. So “À faire” / “En cours” / “Terminé” works exactly the same as the English. The only thing that has to be in English is the vortexiq:finding tag (we write it, so it always is).