> ## 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.
# The Kanban Board: where findings become done work
> The Vortex IQ Kanban Board turns audit findings, Vortex Mind report items, and AI-proposed actions into cards that move through To Do, In Review, Doing, and Done - with automation rules, assignees, and due dates.
The Kanban Board is where Vortex IQ findings become done work. Every audit finding, every Vortex Mind report item, every AI-proposed change, and every customer-journey friction point lands here as a card and moves through the workflow until it is resolved. When a card carries a Vortex Agent fix, it pauses in **In Review** so you approve it before anything ships: the fix then applies staging-first and stays reversible with one-click rollback, so nothing reaches your live store unchecked. The board lives at `app.vortexiq.ai/v2/kanban` and it is the single resolution surface across every other module on the platform.
## Why a Kanban Board inside an AI OS
Most ecommerce teams already use a project tool - Jira, Asana, Linear, Trello, ClickUp, Monday. They are good at tracking work once it is defined. They are not good at *defining the work*: a generic project tool has no idea what is broken, what is underperforming, what is leaking revenue, or what to prioritise. The merchant has to figure that out and enter the work by hand.
The Vortex IQ Kanban Board sits on the other side of that gap. The work is **generated** by the audit and report engines, **prioritised** by the severity model, and **routed** by automation rules. You inherit a board where every card is already a real, ranked, contextualised piece of work with a recommended fix path attached. Your job is to triage, assign, and ship - not to figure out what should be on the board in the first place.
Many teams run both: the Vortex IQ Kanban Board for triage and prioritisation, and Jira (or Asana / Linear) for engineering execution, with bidirectional sync between the two.
## What lives on the board
Cards come from five primary sources, plus manual entry:
| Source | Card type | Routing default |
| ------------------------------------------------- | ---------------- | -------------------------------------- |
| [Store Audit](/actions/store-audit) findings | Audit finding | To Do |
| Customer Journey Test friction points | Journey friction | To Do |
| UI/UX Regression Test regressions | Regression | Critical column / Regressions swimlane |
| Generate New Page proposals | Proposal | To Do with *Proposal* label |
| [Vortex Mind](/vortex-mind/overview) report items | Report action | To Do with *From Vortex Mind* label |
Cards can also be created manually for work that did not originate in an automated source.
## The default board
Out of the box, every workspace gets a board with four columns:
| Column | What it represents | Auto-transition |
| ------------- | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| **To Do** | Cards not yet started - the intake column for every new finding. | None (manual move out). |
| **In Review** | Cards in the proposal- or fix-review stage: an AI-generated fix awaiting approval, or a draft change awaiting team review. | When an Ask Viq fix is approved, the card auto-moves to Doing. |
| **Doing** | Cards actively being worked on. | When a fix lands (deploy event, Bulk Content Edit applied, manual close), the card auto-moves to Done. |
| **Done** | Cards that have been resolved; the finding is marked resolved in Vortex Memory. | None. |
Each column shows its card count in the header so you can see queue depth at a glance. Columns are customisable for workspaces with more complex workflows, and a workspace can run multiple boards (for example, one each for Marketing, Engineering, and Finance) with their own columns, swimlanes, and rules.
## Card anatomy
Every card carries:
| Element | Detail |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Title** | The finding name or work-item title. |
| **Severity badge** | Critical / High / Medium / Low / Informational, mirrored from the originating finding. |
| **Source label** | Which connector or scan surfaced the work. |
| **Assignee** | Who is responsible. Defaults to unassigned; set by rules or manually. |
| **Due date** | Defaults to severity-driven (Critical +24h, High +7d, Medium +30d, Low +90d). |
| **Labels** | Source, finding type, journey, regression, proposal, and custom labels. |
| **Recommended fix** | AI-generated guidance on the lowest-friction resolution. |
| **Affected items checklist** | URLs, SKUs, transactions, or customers ticked off as resolved. |
| **Linked context** | Chips linking to the related [Ask Viq](/ask-viq/overview) conversation, [Vortex Mind](/vortex-mind/overview) report, or mirrored external issue. |
Click any card to expand the full panel with comments, history, attachments, and the complete finding context.
## Filters, search, and swimlanes
A filter rail above the board scopes the view by **source** (Audit, Journey, Regression, Proposal, Vortex Mind, Manual), **severity**, **assignee**, **date range**, and **label**, plus full-text search across titles, descriptions, and comments. Filters stack, the filtered view is shareable via URL, and named filter combinations are saved as quick-access views.
For horizontal grouping, **swimlanes** group cards by source, severity, assignee, team, or storefront - for example one lane per connector, one lane per severity band, or one lane per storefront. Swimlanes can be enabled or disabled per workspace.
## Automation rules
Automation rules drive routing, status transitions, and external integrations. Common rules:
* Route critical findings to **In Review** for engineering review.
* Send SEO findings to the **Marketing** swimlane.
* Send Vortex Mind findings to **Operations**.
* When the linked deploy lands, move the card from **Doing** to **Done**.
* When a card sits in **Done** for 14 days, archive it.
Within a column, cards also carry a finer-grained status (*Awaiting approval*, *Awaiting fix*, *Pending data refresh*, *Blocked*) that is independent of column position.
## Exports and integrations
The board exports to **CSV** (every card with full metadata) and **PDF** (a board snapshot for stakeholder reports). It syncs **bidirectionally with Jira, Asana, and Linear**, and can push events out via webhook - so triage happens in Vortex IQ while execution can continue in your engineering tracker.
## How Kanban connects to other modules
The Kanban Board is downstream of every content-producing module and upstream of your external trackers and long-term memory:
* [Store Audit](/actions/store-audit) findings push to the board.
* [Vortex Mind](/vortex-mind/overview) pushes report actions to the board.
* [Ask Viq](/ask-viq/overview) creates and updates cards from conversation.
* The [SEO + GEO Engine](/actions/seo-geo) publishes content-production cards for the writing team.
* [Bulk Content Edit](/actions/bulk-content-edit) creates cards for batch reviews.
* [Vortex Memory](/vortex-memory/overview) records every card lifecycle event for retroactive analysis and MTTR computation.
## FAQ
No. A workspace can disable the board entirely from **Settings → Kanban**. Findings still surface in the Store Audit findings dashboard and can be routed directly to Slack, Jira, or email. The board is the recommended resolution surface, but it is not mandatory.
Yes. Configure multiple boards (for example, Marketing, Engineering, Finance) with different columns, swimlanes, and automation rules. Cards route by source and severity to the appropriate board. The default workspace board is created on first use.
Yes, bidirectionally. Many merchants use Vortex IQ Kanban for triage and Jira for engineering execution, with the two kept in sync.
Due dates default to severity-driven (Critical +24h, High +7d, Medium +30d, Low +90d). Automation rules can override per source or finding type, and a manual override per card is always available.
If the finding is resolved while the card is still in To Do or In Review, the card auto-moves to Done with a *resolved upstream* note. If the card is in Doing, it stays there (someone is actively working on it) but a banner flags that the finding may already be resolved.