> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # VortexIQ Findings Open, Confluence > Tickets we created from audit findings that haven't been resolved yet. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Project Management](/nerve-centre/connectors#connectors-by-type) > 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 | ```text theme={null} Open count = 14 + 6 + 11 + 3 = 34 ``` The card shows **34** and the alert fires (threshold is `>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)](/nerve-centre/kpi-cards/confluence/abandoned-findings) | 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)](/nerve-centre/kpi-cards/confluence/finding-resolution-rate) | Throughput. | Open growing + Resolution Rate falling = capacity issue. Open growing + Resolution Rate stable = inflow surge. | | [Avg Time-to-Fix](/nerve-centre/kpi-cards/confluence/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](/nerve-centre/kpi-cards/confluence/tickets-by-assignee) | Load distribution across `vortexiq.assignee`. | Concentration on one person is a routing problem. | | [Backlog by Priority](/nerve-centre/kpi-cards/confluence/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: > > ```cql theme={null} > space = VFND AND label = "vortexiq-finding" AND macro = "details" > ``` > > Then filter the results page by the `vortexiq.status` value not in `done, wont_fix, duplicate`. 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:** | 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*. | **Cross-connector reconciliation. Confluence vs Jira (Atlassian-suite):** In Atlassian-suite-merchants, the most common pattern is *both* connectors enabled with Confluence-primary routing. In that mode, every finding-page in Confluence has a 1:1 linked Jira issue. The `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. Vortex IQ's two-way sync handles this automatically; manual edits in either tool by your team can briefly desync. The 15-minute reconciliation re-aligns them. ## 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 of `vortexiq.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 Key Metrics 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 Key Metrics 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. *** ### Tracked live in Vortex IQ Nerve Centre *VortexIQ Findings Open* is one of hundreds of KPI pulses Vortex IQ tracks across Confluence and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.