Tickets we created from audit findings that haven’t been resolved yet.
At a glance
Live count of Confluence pages Vortex IQ created from audit findings that are not yet marked closed. Confluence is unusual for finding-tracking: it’s a wiki, not a ticket system. Vortex IQ writes findings as pages in a dedicated Space, with a vortexiq.status page property as the open/closed signal.
| What it counts | Pages in the merchant-mapped Findings Space whose vortexiq.status page property is not in the closed set. Each page is one finding. Child pages count separately if they carry their own vortexiq.status property. |
| Confluence Space scope | One Space per connected workspace, named at setup (Settings → Connectors → Confluence → Findings space, default key VFND). Vortex IQ does NOT crawl other Spaces, your engineering wikis, runbooks, and corporate docs are invisible to this count. |
| Why a wiki for finding-tracking | Confluence as a finding destination suits teams that want rich, durable evidence (screenshots, query results, video clips) attached to each finding, postmortem-style. Lightweight ticketing belongs in Jira. |
| Atlassian-suite integration | If both Jira and Confluence connectors are enabled, Vortex IQ can either (a) write findings to Confluence with auto-linked Jira tickets for tracking, or (b) write to Jira only with auto-linked Confluence runbook pages. Choose in Settings → Connectors → Atlassian routing. This card counts the Confluence pages regardless of routing mode. |
| Status filter | Open = vortexiq.status ∈ {open, investigating, in_progress, blocked}. Closed = {done, wont_fix, duplicate}. We write the values; merchants can override via the page-properties macro on each finding page. |
| Page property scheme | Three Confluence page properties: vortexiq.status (string), vortexiq.priority (string: low / medium / high / critical), vortexiq.assignee (Confluence user account ID). Set via the page-properties macro at the top of each finding page. |
| Resolution counts | A page drops out of this count when vortexiq.status becomes any closed value. The page itself is not deleted, the historical evidence stays in Confluence forever. |
| Sync mechanism | Confluence webhooks (page_updated) plus 15-minute reconciliation via the Cloud REST API (/wiki/api/v2/pages). |
| Time window | RT (real-time, latest sync). |
| Alert trigger | >20 open |
| Roles | owner, operations |
Calculation
Calculated automatically from your Confluence 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 US enterprise retailer running Adobe Commerce, with engineering on Atlassian Cloud (both Jira and Confluence). Their Findings Space (VFND) holds 58 finding-pages. Routing mode: Confluence-primary with auto-linked Jira tickets for tracking. Snapshot taken on 24 Feb 26.
vortexiq.status value | Pages | Counts as open? |
|---|---|---|
| open | 14 | yes |
| investigating | 6 | yes |
| in_progress | 11 | yes |
| blocked | 3 | yes |
| done | 19 | no |
| wont_fix | 4 | no |
| duplicate | 1 | no |
>20). The dashboard banner reads “34 open findings in Confluence VFND space, queue grew by 6 this week”. The team’s Jira board mirrors the Confluence pages (each finding-page has a linked Jira issue), and Jira’s con_vortexiq_findings_open card shows the same 34 (because the Jira tickets and Confluence pages are 1:1 for this merchant’s routing mode).
Why the page count and the open count can differ: the Findings Space is allowed to contain other content too (runbooks, postmortem templates, agendas). Only pages with the vortexiq.status page-property set are findings. A blank Space has 0 findings even if it has 100 wiki pages.
Why some merchants run this Space alongside Jira: Confluence pages support arbitrarily long-form content (incident timelines, before/after screenshots, even embedded Loom videos). The Jira ticket carries the workflow status; the Confluence page carries the evidence. For audit findings that may need to be revisited 6 months later, the evidence trail matters as much as the ticket.
Sibling cards merchants should reference together
Open Findings is the queue depth. Read it next to:| Card | Why it matters next to Open Findings | What the combination tells you |
|---|---|---|
| Abandoned Findings (>14d no movement) | Open includes all unclosed; abandoned isolates the un-touched. | If 30%+ of Open is also Abandoned, the queue is rotting, not busy. Different intervention. |
| Finding Resolution Rate (90d) | Throughput. | Open growing + Resolution Rate falling = capacity issue. Open growing + Resolution Rate stable = inflow surge. |
| Avg Time-to-Fix | Per-finding speed. | High Open + low Time-to-Fix = healthy. High Open + high Time-to-Fix = systemic slowdown. |
| Tickets by Assignee | Load distribution across vortexiq.assignee. | Concentration on one person is a routing problem. |
| Backlog by Priority | What’s actually open by importance. | If 80% of Open is low priority, focus on closing-by-decision (Won’t fix) before adding capacity. |
Reconciling against the vendor’s own dashboard
Where to reproduce this in Confluence itself: Confluence does not have a finding dashboard, but you can replicate ours with a CQL (Confluence Query Language) search:Open Confluence → top-bar search → click “More” → “Advanced search” → switch to CQL. Query:The simpler alternative: open the Findings Space → use the Page properties report macro that we install during connector setup. It shows a live table of every finding-page with its status, priority, assignee, and last-edited date. The row count where status is not closed should match this card. Why our number may legitimately differ from your CQL or page-properties report:Then filter the results page by thevortexiq.statusvalue not indone, wont_fix, duplicate.
| Reason | Direction | Why |
|---|---|---|
| Sync lag | Ours lower | We refresh on page_updated webhook + 15-minute reconciliation. A status change you made in the last minute may not yet be in our count. |
| Drafts | Ours lower | A finding-page in Draft (never published) is invisible to the API and so to us; but it shows in the merchant’s My drafts sidebar. We only count published pages. |
| Restricted pages | Either | If a finding-page has page restrictions enabled and our integration user is excluded from the restriction, we cannot read its vortexiq.status and exclude it. The merchant viewing as themselves may see it. Recommend not adding page restrictions on the Findings Space. |
| Soft-deleted pages | Ours lower | Confluence keeps deleted pages in the Trash for 30 days. We exclude trashed pages immediately; “All pages” views may include them. |
| Wrong Space mapped | Ours zero | If the merchant has multiple Spaces, e.g. moved findings to a new Space VFND2, our connector is still pointing at the old Space, the count looks artificially low. Re-map in Settings → Connectors → Confluence → Findings space. |
con_vortexiq_findings_open and jir_vortexiq_findings_open cards should match within the sync window. If they diverge by more than 2, 3:
- A finding-page was closed in Confluence (page-property updated) but the Jira issue wasn’t moved to Done, OR
- A Jira issue was moved to Done but the linked Confluence page-property wasn’t updated.
Known limitations / merchant FAQs
Why is my count rising? Three usual culprits: (1) inflow exceeds outflow, the team isn’t moving page-properties to Done, check Resolution Rate; (2) a teammate manually edited the page-properties macro and broke the property name (e.g. capitalised “Status” instead ofvortexiq.status); (3) a new Confluence Space was created for “Q2 audits” and findings are now being written there but the connector is still pointing at the old Space.
Why use Confluence at all if we have Jira?
For audit findings that need long-form evidence (screenshots, query results, postmortem-style writeups), Confluence pages are a better fit than Jira issue descriptions, which become cluttered fast. The recommended pattern: Jira tracks workflow status, Confluence holds the evidence, and Vortex IQ links them automatically.
My team accidentally moved a finding-page to a different Space, what happens?
The connector follows pages by ID, not by Space, so it will continue counting the page wherever it lives. However, your team’s view of the Findings Space will no longer show that page. We recommend keeping all finding-pages in the mapped Space; if you need to archive old findings, change vortexiq.status to a closed value rather than moving the page.
Can I filter by vortexiq.priority to see only critical open findings?
Not from this card directly. Use Backlog by Priority for the breakdown, or in Confluence open the page-properties report and filter by priority. The hero card stays a single count on purpose.
The page-properties macro disappeared from one of our finding-pages, what happened?
Someone deleted it (Confluence allows free editing of any page). Without the macro, the page has no vortexiq.status, so we can’t tell whether it’s open or closed and exclude it from the count. Re-add the macro or run Settings → Connectors → Confluence → Repair page properties to re-insert macros on all finding-pages.
Does the count include archived Spaces?
No. Archived Spaces are returned by Confluence’s API with an archived: true flag and we exclude them. If your team accidentally archived the Findings Space, this card drops to zero, the fix is to un-archive in Confluence Admin → Spaces.
Why “20 open” as the alert? Our team handles 50+ comfortably.
Default calibrated for a small ecommerce team. Adjust in Settings → Connectors → Confluence → Alerts → Open findings threshold. Rule of thumb: 2× typical weekly resolution rate.
Can the card count across multiple Spaces?
Not today. One mapped Space per workspace. Reasons: (1) ambiguous SLA tracking when findings live in multiple places, (2) Confluence’s permission model is per-Space, mixing Spaces can hide pages from the integration user. If you genuinely need separate Spaces (e.g. one per business unit), connect Vortex IQ as separate workspaces.
My Confluence is on Server / Data Center, not Cloud. Does this work?
The connector currently supports Atlassian Cloud only. Server / Data Center support is on the roadmap for late 2026.
Why is this a Hero card?
Because it’s the single most-asked operational question for Atlassian-suite merchants: “how many open audit findings are sitting in our docs?”. One number, scannable in 1 second, gates everything else.