> ## Documentation Index
> Fetch the complete documentation index at: https://docs.autosana.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Jira Cloud

> Connect Jira Cloud and choose where Autosana creates tickets

Autosana supports Jira Cloud through Atlassian OAuth. Jira Server and Jira Data
Center are not supported.

## Connect Jira Cloud

You must be an Autosana workspace admin or owner to install and configure Jira.

1. Go to **[Settings > Integrations > Jira](https://autosana.ai/settings?tab=integrations\&integration=jira)**
2. Click **Connect Jira** and approve the Atlassian authorization request
3. If your Atlassian account can access multiple sites, choose the Jira site
4. Select the default project and issue type

Autosana requests these Atlassian scopes:

* `read:jira-work` to read projects, issue types, and ticket status
* `write:jira-work` to create tickets and add recurrence comments
* `manage:jira-webhook` to register ticket-status webhooks
* `offline_access` to refresh the connection without asking you to sign in again

<Note>
  The selected project and issue type are defaults. You can choose a different
  available destination in the ticket review dialog before creating a ticket.
</Note>

## Create and review tickets

Select **Create ticket** on an Autosana issue group or an individual issue in a
flow run. The review dialog includes:

* Jira or Linear as the provider
* the destination project
* the Jira issue type
* an editable title and description with Autosana evidence links

Autosana shows the Jira key after creation and keeps completed and failed
attempts in the issue group's ticket history. It blocks another ticket while a
ticket is open, pending, or has an unknown creation result.

If the same issue returns after its Jira ticket was completed, Autosana offers a
linked regression ticket. The previous provider, project, and issue type are
reused only while they remain available; otherwise you must select a new
destination.

## Automatic tickets

Automatic ticket creation is **Off** for new connections. Workspace admins can
choose one automatic provider under **Settings > Integrations**: **Off**,
**Jira**, or **Linear**. During migration, an eligible existing Linear
connection with a configured default team preserves its prior automatic
behavior.

When Jira is selected, Autosana creates at most one current ticket for each new
critical issue group. Jira must have a valid default project and issue type and
healthy webhook delivery. Issues marked **Don't show again** never create
automatic tickets.

## Webhook health and reconnecting

Jira webhooks normally update Autosana when a ticket changes status. The Jira
settings card shows webhook health and the latest verified delivery. Autosana
also reconciles stale ticket status and renews webhook registrations to repair
missed or expiring subscriptions.

Reconnect Jira when the settings card reports that authorization is required.
If a project or issue type was removed, choose a new default before enabling
automatic creation.

To remove the connection, select **Disconnect Jira** from the Jira settings
card. Existing Autosana ticket history remains available, but new Jira ticket
creation and status updates stop until Jira is connected again.

## Operator rollout and rollback

Use this order when enabling provider-backed ticketing in a hosted environment:

1. Apply the additive/rename migration and deploy backward-compatible backend reads.
2. Configure Atlassian OAuth callback and approve distribution/sharing for Jira Cloud tenants.
3. Configure Jira, Linear, and Slack webhook secrets and public callback URLs.
4. Reauthorize existing Linear installations so webhook permissions/secrets are present.
5. Enable the PostHog `ticketing-integrations` UI flag for internal organizations, then a small customer cohort.
6. Monitor unknown creates, webhook age, reconciliation failures, Slack interaction latency, and blocked grouping maintenance.
7. Expand rollout; for a normal cohort rollback, disable the PostHog flag and `automatic_provider` while leaving the deploy runtime enabled so ticket history and webhook ingestion continue.

`TICKETING_INTEGRATIONS_ENABLED` is the deploy-level runtime switch, separate
from the PostHog UI flag. Setting it to `false` removes the provider, ticket,
and webhook routes and stops ticketing background work. Reserve it for a full
runtime shutdown, not a normal UI/cohort rollback.