Tickets we created from audit findings that haven’t been resolved yet.
At a glance
The live count of shapes / cards on the configured Lucidchart document where the VortexIQ-finding tag is present and the item has not been moved to a “Done” container or layer. Lucidchart is documentation-first (flowcharts, ERDs, network diagrams) rather than triage-first, so this card is uncommon and most useful when the team has explicitly chosen Lucidchart as their delivery surface (rare). For most teams, audit findings should route to Jira or Asana; Lucidchart is preserved as a connector for completeness and for the small population of teams that genuinely use it as a Kanban-style board.
| What it counts | Shapes / cards on the configured Lucidchart document, tagged vortexiq:finding, whose containing layer or shape-cluster is not labelled Done. Because Lucidchart has no native column / Kanban convention, status detection relies on the document’s shape.containerData.label field. |
| Document / folder scope | The single Lucidchart document configured on the connector. Lucidspark (the whiteboard sibling) is a separate connector type. |
| Status filter | ”Open” means anything not inside a Done-labelled container. Free-floating shapes (not inside any container) count as open. |
| Item type filter | Shapes with the vortexiq:finding tag (custom data attribute). Connector lines, free-text labels, and shape-groups without the tag are skipped. |
| Resolution counts | A finding leaves the count when someone moves the shape inside a Done container or deletes it. Lucidchart’s collaboration model is mostly co-edit on a shared diagram; webhook events fire for shape mutations but not for selection / view. |
| Time window | RT (Lucidchart REST API polled every 60 seconds; webhook-driven on Enterprise plans). |
| Alert trigger | >20 open. Same calibration as Miro / Asana / Jira; teams using Lucidchart as a tracker tend to be small and structured, so 20 is a reasonable ceiling. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Lucidchart 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 small B2B brand on BigCommerce uses Lucidchart for two purposes: documenting their integration architecture, AND running a lightweight ops Kanban on a separate document called Storefront Ops Kanban. Most merchants on Lucidchart only do the first; this brand does both. The Kanban document has four containers: Inbox, Owned, In review, Done. Snapshot taken on 02 May 26 at 09:00 EDT.| Container | Shapes tagged vortexiq:finding |
|---|---|
| Inbox | 6 |
| Owned | 4 |
| In review | 2 |
| Done | 19 |
| Free-floating (not in any container) | 1 |
- 4 of the 6 Inbox shapes are tagged
severity:mediumERD-related findings (schema drift between docs and live database). - The In-review pair are documentation-fix tasks for the team’s onboarding diagrams.
- The free-floating shape is an idea sketched outside any container, probably needs to be triaged into Inbox or deleted.
vortexiq:reference (so it stops counting). At the next standup, assigns owners to the 6 Inbox shapes. The 13-open count is fine; the team is using Lucidchart as a low-volume parallel tracker for documentation-tied audit findings (the kind of work Jira would feel heavy for).
Why this is unusual: Lucidchart is not built for triage. Most merchant teams that use it for tracking are small (1-5 people), heavily diagram-led (architecture, IA, dataflow), and want their audit findings sitting next to the diagrams that explain the system rather than in a separate tracker. The card is healthy, but if the open count rises above 20 the team should question whether Lucidchart is still the right surface; once you cross 20 items, the diagram-context advantage erodes and a proper tracker becomes a better tool.
Compare to Miro / Mural / Jira: Miro flows continuously, Mural bursts around workshops, Jira enforces workflow. Lucidchart is the slowest and lowest-volume of the four, often staying at 5-10 open for weeks. The 20-open alert is therefore a stronger signal here than on any of the others, when Lucidchart’s open count exceeds 20, the team has likely outgrown Lucidchart as a tracker.
Sibling cards merchants should reference together
| Card | Why pair it with VortexIQ Findings Open | What the combination tells you |
|---|---|---|
| Abandoned Findings (>14d no movement) | Subset of Open. The “stuck on the diagram” tail. | Lucidchart abandonment is rare but meaningful; a stuck shape on a documentation diagram usually means the doc itself is wrong, not just the work-item. |
| Finding Resolution Rate (90d) | The flow ratio over a quarter. | At Lucidchart’s typical low intake, a meaningful rate may need 30+ items in the window; below that the rate is too noisy. |
| Throughput Trend | Closure rhythm. Expect very flat lines on Lucidchart. | Bursts are rare; consistent low-volume flow is the healthy signature. |
| VortexIQ Findings Resolved (90d) | Completion peer. | If Resolved climbs while Open stays flat, the team is delivering at intake-rate (steady state). |
| Miro VortexIQ Findings Open | Visual-collab peer. Real-time-flow oriented. | Same metric, different cadence. Most teams pick one tool; both populated implies migration or dual-tool use. |
| Jira Critical Findings Without a Jira Ticket | Coverage-gap card. If criticals are landing on Lucidchart instead of Jira, the auto-routing is wrong. | High-severity items belong on a tracker that escalates; Lucidchart cannot. |
Reconciling against the vendor’s own dashboard
Where to look in Lucidchart’s own dashboard: Lucidchart does not have a “tasks” or “open work” view, the product is a diagramming tool, not a tracker. The closest manual reconciliation is to open the configured document, use the Find feature to search for shapes with thevortexiq:finding custom data attribute, and visually count those outside the Done container.
Lucidchart → open the configured document → Edit menu → Find / Replace (orFor most merchants this is a 30-second check, which is one reason the card is low priority: the manual reconciliation is so easy that automated reading mostly serves dashboard consistency rather than time-saving. Why our number may legitimately differ from a manual count:Ctrl-F) → entervortexiq:finding→ results pane lists matching shapes by container → manually count rows where Container ≠ “Done”.
| Reason | Direction | Why |
|---|---|---|
| Container detection | Either | The connector reads containerData.label. If the team uses a custom container shape without a label, status detection falls back to position (slower, less reliable). |
| Multi-page documents | Ours higher | If the document spans multiple Lucidchart pages and only one page has a Done container, items on other pages count as open even though they may be intentionally permanent (architecture diagrams, ERDs). Solution: vortexiq:reference tag on permanent shapes. |
| Polling cadence | Ours stale up to 60s | Lucidchart Enterprise sends webhooks; lower tiers rely on polling. |
| Document permissions | Possible undercount | Shapes on a layer the connector cannot access (private layers on Enterprise) are invisible to Vortex IQ. |
| Lucidspark vs Lucidchart | Confusion | Lucidspark (whiteboard) is a separate connector. If the team accidentally configured the Chart connector against a Spark document, the API responses are inconsistent. Verify the connector type matches the document type. |
| Time zone | None | Real-time count, no period boundary. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
miro.mir_vortexiq_findings_open | Same metric on Miro. Different volume profiles. | Miro is real-time and high-volume; Lucidchart is documentation-led and low-volume. Direct comparison is rarely useful unless the team uses both. |
mural.mur_vortexiq_findings_open | Same metric on Mural. | Mural is workshop-bursty; Lucidchart is steady-trickle. Same number means very different things. |
jira.jir_vortexiq_findings_open | Engineering-canonical peer. | If Jira has 50+ open findings while Lucidchart has 3, the team is correctly using Jira for delivery and Lucidchart for documentation. |
Known limitations / merchant FAQs
Why are Vortex IQ findings going into Lucidchart? It’s a diagramming tool, not a PM tool. Because some operations teams use Lucidchart’sLucidspark boards (sticky-note + whiteboard hybrid) as their primary planning surface, particularly post-incident review boards, cross-team architecture-change boards, and customer-journey audit boards. When a merchant configures Lucidchart as the outbound destination for Vortex IQ findings, the findings appear as cards on the designated Lucidspark board. Lucidchart is unusual among the supported destinations and is best suited for teams who already review findings in Lucidspark; if your team uses Jira, Asana, Linear, or ClickUp as the primary, route findings there instead.
My team uses Lucidspark cards but the count looks low. Why?
Three common causes. (1) The Lucidspark board specified in connector setup has been archived or deleted; new findings appear in a hidden or stale board nobody monitors. (2) The Lucidspark API key is scoped to a different team than the one running ops; findings are written to a board the ops team cannot see. (3) Findings are routed elsewhere by default: if your organisation also has Jira or Asana connected, the routing priority may favour the engineering tool. Confirm the routing in Settings, Connectors, Routing.
The count on this card is much smaller than my live Lucidspark board count. Why?
Because the card filters to cards with the vortex_iq_finding tag specifically. Any card created by humans, by other integrations, or by Lucidchart’s own templates does not count. The card is only Vortex IQ-attributed findings, not the broader Lucidspark inbox.
My team uses multiple Lucidspark boards (one per quarter). Does the card aggregate across them?
Yes if all boards are connected through a single Lucidchart integration. The card sums findings across every board the connector token can read, intersected with the boards tagged vortex_iq_outbound in connector setup. To break out by board, build a Stacked Panel in Vortex IQ Nerve Centre with one panel per board.
A finding card was moved to a different Lucidspark board manually. Does it still count?
Yes, as long as the destination board is also tagged vortex_iq_outbound and the card retains the vortex_iq_finding tag. Lucidspark cards do not lose their tag when moved; the finding stays in the count until explicitly closed (set to the done state via the Lucidspark API) or deleted.
How do I close a Vortex IQ finding card in Lucidspark?
Two ways. (1) Move the card to a section labelled done, closed, or won't fix: the connector watches for these section names and updates the card state accordingly. (2) Delete the card: removing it from the board takes it out of the count immediately. Most teams use the section-move approach because it preserves the audit trail; deletions are common when a finding turns out to be a duplicate.
Open count dropped suddenly. What changed?
Three usual causes, in order of likelihood. (1) A teammate did a bulk move-to-done from the Lucidspark UI; check the Lucidspark version history. (2) A board was archived; archived boards drop out of the count immediately. (3) Vortex IQ outbound was paused at the account level; check connector status in Settings, Connectors.
Why doesn’t this number match the count of recent Vortex IQ findings on my dashboard?
The Vortex IQ findings count and the Lucidspark open count diverge by design. The findings count is what the audit found across the last 7 / 30 / 90 days; this card is what Lucidspark currently has open. Older findings that were resolved drop out of this card but stay in the long-window finding totals.
Is Lucidchart the right destination for our context?
Lucidchart is the right destination if your team already reviews findings on Lucidspark boards (post-incident reviews, cross-team architecture change boards, customer-journey audit workshops). If your team treats audit findings as engineering tickets with cycle times measured in sprints, Linear or Jira is a better fit. If your team treats them as operations workflows with daily triage, Asana or Trello is closer. Lucidchart’s strength here is visual context: a finding card sitting next to a customer-journey diagram or a system-architecture map gives spatial context that linear PM tools cannot.
My team uses Lucidchart but you also have Jira connected. Will Vortex IQ duplicate findings into both?
No. Each finding is routed to one PM tool based on the connector setup’s outbound priority. Default is Jira if connected (engineering-led), then Asana, then Lucidchart, then Trello. Override in Settings, Connectors, Routing if your operations team owns the queue regardless of engineering involvement.
Today’s count looks volatile. Why?
At low volumes (<10 open) a single close or new finding moves the count by 10%+ which can register as visual noise. The 30-day average and the 7-day rolling are the steadier reads for trend; the headline number is the live count. Lucidspark-using teams typically have lower finding volumes than Jira-using teams because Lucidchart is rarely the primary PM tool.
Why is the alert threshold 20 and not 30 or 50?
20 reflects the typical Lucidspark-board capacity. Lucidspark boards become hard to navigate above 30 to 40 cards regardless of card type; a Vortex IQ count of 20 means roughly 50 to 70% of board capacity (assuming the team also uses the board for non-finding work). Tunable per organisation in connector settings.
Can the connector write screenshots or diagrams to the finding cards?
Yes for screenshots; partial for diagrams. The connector attaches screenshots from the Vortex IQ audit to the finding card body. Auto-generated diagrams (e.g. customer-journey maps for journey findings) are written as embedded Lucidspark elements when the audit produces them; this is the killer feature that justifies routing to Lucidchart at all. If the audit did not produce a diagram (most findings do not), the card is text-only.