Jira Cloud integration

Connect a Jira Cloud site to AvsB and tickets are auto-filed when experiments declare winners, breach guardrails, or other mapped events fire. Tickets show smart-card previews of the AvsB results page, and the AvsB results page lists every linked ticket with its current status.

Only Jira Cloud sites on the Standard, Premium, and Enterpriseeditions are supported. Jira Server and Data Center are out of scope. Free is blocked because Atlassian's rate limits on the Free edition are incompatible with our ticket-creation cadence.

Prerequisites

You must be a Jira site admin (or have Browse projects + Create issues on at least one project).
You need the Manage integrations permission in AvsB.
The AvsB Atlassian app must be installable on your tenant (no marketplace listing required for the OAuth handshake).

Connecting a Jira site

Open Organisation Settings → Integrations in AvsB.
In the Jira card, click Add Jira destination.
Click Connect Jira site. You will be redirected to Atlassian to authorize the AvsB app.
Pick the Jira site to connect, review the permissions, and approve.
You will be redirected back to AvsB with the site listed in the modal.

AvsB stores an OAuth refresh token (encrypted at rest) so the connection survives access-token expiry. A background worker refreshes access tokens every 30 minutes when they fall within 60 minutes of expiry.

Mapping a project + event types

Each Jira destination is bound to a single project. The create-flow surfaces a table of notification events; toggle the ones you want to file tickets for and customize each row:

Issue type — defaults: Task for rollouts, Bug for safety events.
Priority — defaults: Medium for rollouts, High for safety events.
Summary template — supports {{variable}} substitution.
Description — defaults to a structured ADF doc with key stats, configuration, and a smart-card preview link. You can supply a custom plain-text or ADF JSON template.
Labels — applied to every issue created from this event type.

Default mappings

Event	Issue type	Priority	Default summary
`experiment.winner_declared`	Task (labelled `rollout`)	Medium	`[Rollout] {{winnerVariationName}} won on {{experimentName}}`
`experiment.guardrail_breached`	Bug (labelled `incident`)	High	`[Guardrail] {{guardrailMetric}} breached on {{experimentName}}`
`experiment.srm_failed`	Bug (labelled `investigation`)	High	`[SRM] Sample-ratio mismatch on {{experimentName}}`
`flag.rule_activated`	Task (labelled `flag-rollout`)	Low	`[Flag rule live] {{ruleName}} on {{flagName}}`
All other events	Disabled by default — toggle on if you want them.

Template variables

Available variables per event type. Unknown variables render as an empty string.

Event	Variables
`experiment.winner_declared`	`experimentName`, `winnerVariationName`, `primaryMetricName`, `lift`, `confidence`, `sampleSize`, `engine`, `declaredAt`, `resultsUrl`
`experiment.guardrail_breached`	`experimentName`, `guardrailMetric`, `observedValue`, `thresholdValue`, `breachDirection`, `detectedAt`, `resultsUrl`
`experiment.srm_failed`	`experimentName`, `observedRatio`, `expectedRatio`, `pValue`, `detectedAt`, `resultsUrl`
`flag.rule_activated`	`flagName`, `ruleName`, `environment`, `activatedAt`, `activatedBy`, `resultsUrl`

Custom ADF descriptions

Description templates accept either plain text with mustache placeholders or a full Atlassian Document Format JSON document. ADF JSON must be a top-level doc node:

1{
2  "version": 1,
3  "type": "doc",
4  "content": [
5    { "type": "paragraph", "content": [
6      { "type": "text", "text": "Winner: " },
7      { "type": "text", "text": "{{winnerVariationName}}", "marks": [{ "type": "strong" }] }
8    ]},
9    { "type": "paragraph", "content": [{ "type": "inlineCard", "attrs": { "url": "{{resultsUrl}}" } }] }
10  ]
11}

Bodies exceeding Jira's 32KB description limit are truncated automatically with a clear note at the end.

De-duplication and comment-on-existing

If a notification event fires twice for the same (experiment, event) pair — for example, a guardrail re-breaching the same metric — AvsB does not file a second ticket. Instead, it adds a comment to the existing open ticket. A ticket is considered "open" while its Jira status category is not done or closed.

A nightly status-sync cron updates the cached status for every link created in the last 90 days. Once a ticket transitions to Done, the next matching event re-files a new ticket.

AvsB-side linked tickets panel

Every experiment results page and flag rule results page now shows a Linked Jira tickets panel. Each row displays the issue key (clickable), the current status, the event that spawned it, and the create date.

You can also link a Jira ticket manually — click Link a Jira ticket, paste an issue key like ROLL-1234, and pick which Jira destination it belongs to.

Sending a test ticket

Each Jira destination card has a Send test ticket button under Organisation Settings → Integrations. Click it to open a modal that shows the site, project, and configured issue type pulled from the destination, plus an event-type picker (default experiment.guardrail_breached, the canonical "here's what a real ticket looks like" event).

On success the modal shows the created issue key with an Open in Jira ↗ link and a Delete this test ticket button — click Delete and the synthetic ticket is removed from your Jira project so verification leaves no permanent footprint. The created ticket is also prefixed [TEST] and labelled avsb-test-ticketfor easy identification if you choose to leave it. On failure the modal surfaces Jira's error message (project not found, issue type invalid, scopes insufficient, expired refresh token, …).

Requires the manageIntegrations permission. Both the send and the delete are audited (JIRA_TEST_TICKET_SENT / JIRA_TEST_TICKET_DELETED).

Audit log

The following audit actions are recorded for Jira:

JIRA_SITE_CONNECTED / JIRA_SITE_DISCONNECTED / JIRA_SITE_REVOKED
JIRA_ISSUE_CREATED / JIRA_ISSUE_COMMENTED
JIRA_TEST_TICKET_SENT / JIRA_TEST_TICKET_DELETED
JIRA_LINK_CREATED_MANUALLY / JIRA_LINK_REMOVED
JIRA_TEMPLATES_UPDATED / JIRA_TEST_TICKET_SENT

Troubleshooting

Token expired

The destination card displays a banner if Atlassian rejects the stored refresh token. Click Reconnect to run the OAuth flow again. Pending deliveries re-queue automatically once the connection is restored.

Project moved or archived

A 403 or 404 from Jira disables the destination and surfaces a repair banner. Edit the destination, pick the new project, and the route resumes.

Ticket was created but I expected a comment

AvsB's dedup logic considers a ticket open while its status category is indeterminate, new, or open. If your workflow uses a custom status category that maps to done, that ticket is treated as closed and the next event will file a new one.

Issue type doesn't exist in our project

If a Jira admin renames or deletes an issue type, the next create call fails with 400. The destination shows a Refresh templatesaction that re-fetches the project's issue types and prompts you to re-map.