Bugs that arrive in Jira with their proof.
Connect once, then push approved findings as typed issues: a bug lands as a Jira Bug with severity mapped to priority, the verbatim quote, and a link to the second it happened. Setup takes about two minutes.
Five steps, admin required for the first four.
After step 4, everyone on the team with the member role can push.
- STEP 01
Open the integrations settings
In the app, go to Settings, then Integrations under Push destinations. Connecting a destination needs a workspace admin or owner; members can push once it is connected.
- STEP 02
Connect Jira
On the Jira card, choose Connect. Sign in with Atlassian and approve the requested access - read and write work items, read user info - shown in the dialog before you approve. Prefer a token? The same dialog accepts your Jira site URL, email, API token, and project key instead.
- STEP 03
Pick the project
After connecting, the destination picker lists your Jira projects live from your site. Pick the one findings should land in. Issue type is not something you pick: it follows the finding type automatically.
- STEP 04
Confirm the card reads connected
The Jira card now shows the connected project and site (for example "KAN on acme.atlassian.net"). Pasted credentials are checked with Jira before they are saved, so a typo is caught in the dialog rather than on the first push.
- STEP 05
Push an approved finding
Open a recording, approve a finding on the Artifacts tab, and choose Push. Jira appears as a destination; the app confirms "Queued", and Integration activity in Settings shows the delivery through to the created issue key, linked.
The field mapping, exactly.
No configuration needed: the mapping follows the finding.
A bug becomes a Jira Bug, a requirement becomes a Story, everything else becomes a Task.
Finding severity maps to Jira priority: critical to Highest, high to High, medium to Medium, low to Low.
The finding title.
The finding description, the verbatim evidence quote as a blockquote, and a link that opens the recording at the exact second the evidence occurred.
Delivery is queued and tracked: automatic retries happen behind the scenes, the activity panel shows every delivery through to the linked issue key, and pushing unchanged content twice is recognised rather than duplicated. Custom field mapping is not configurable today.
From UAT session to sprint board.
- 1. The UAT recording finishes processing; three bugs are extracted.
- 2. The QA lead reviews each bug against its frame and quote, approves two, rejects one as duplicate.
- 3. Push both approved bugs. Each is queued, then delivered as a Jira Bug in the UAT project.
- 4. The push dialog now shows "Already in Jira" with its issue key on each - pushing again after an edit updates the same issues.
- 5. The developer opens UAT-231, clicks the evidence link, and watches the failure happen at 14:23.
Four states and their fixes.
- "Reconnect needed" on the card
Jira stopped accepting the credential - a revoked grant or expired token. Reconnect from the card; the chosen project is kept.
- No project chosen
A connection without a destination cannot deliver. Open the card and pick the project.
- The delivery shows Failed
Open Integration activity: the row carries the reason and a Retry button. Retrying a delivery never creates a duplicate issue.
- The project disappeared
If the Jira project was deleted or your access to it was removed, deliveries to it fail. Pick a new project from the card.
Every delivery state is listed in the troubleshooting guide.
Jira integration, answered.
- A paid Citesvue plan (pushing is included on Pro and above; connecting is available on every plan), the workspace admin role in Citesvue, and an Atlassian account that can create issues in the target project. Jira Cloud is supported.
- In your Atlassian account settings under Security, then API tokens - the connect dialog links there directly. The token acts as the account that owns it, so issues are created as that user.
- Citesvue remembers the Jira issue it created and updates it in place instead of filing a duplicate. The push dialog shows "Already in Jira" with the issue key, and the button becomes "Push again".
- Findings must be approved before they can be pushed - the review step is what makes the tracker trustworthy. Viewers cannot push on any plan; members and above can.
- Jira and Linear deliberately take one finding per issue - a tracker full of auto-filed bulk tickets helps nobody. For batch delivery, Notion and Slack accept a whole set of findings as one organised page or message.
- Credentials are encrypted at rest and never shown back in full. Disconnecting forgets the credential immediately; issues already created stay in Jira.
- Citesvue forgets the credential and stops sending. Delivery history and the links to already-created issues remain visible. Reconnect at any time; if old deliveries had failed before the disconnect, push them again from the source rather than retrying.
Your next recording could be
your most
valuable asset.
Or it could sit in a Drive folder nobody opens again. The difference is whether it has citations attached.
- SetupOne drag-and-drop upload, or send the notetaker. No plugins.
- First insightCited Q&A on a 60-min recording in under 6 minutes.
- Cancel anytimeFull data export, full right to erasure.