# Jira (ITSM)

> Turn recommendations into Jira tickets; manually, or automatically by policy; with two-way status and ownership sync.

Source: https://zop.dev/docs/zopnight/integrations/jira

---

Recommendations only save money once someone acts on them, and in most orgs "acting" means a ticket. The Jira integration turns a recommendation into a real Jira issue; on demand or automatically by policy; and keeps the recommendation and the ticket in agreement as either side changes.

![Settings Integrations tab showing Atlassian Jira connected with site, default project, and issue type, above AI provider connections](https://storage.googleapis.com/zopdev-blog-resources/1/files/originals/20260707/47551343-64c5-4278-ba8a-39debafe74a0-integrations.png)

*Settings → Integrations; Jira connected with its default project and issue type (AI provider connections sit on the same page).*

## Connect Jira

From **Settings → Integrations** (admin-only), provide the base URL, project key, issue type, bot email, and API token. The token is encrypted at rest. The connect call **verifies the credential live** before saving; a successful connect is the proof, shown as **Connected ✓**; a bad token, missing permission, or unreachable host returns a categorised error.

**Note**

Both Atlassian API-token kinds work. A **classic** token authenticates against your site URL directly. A **scoped** (granular) token connects through the Atlassian API gateway automatically. With a scoped token, outbound ticketing works immediately; inbound two-way sync needs a classic token plus a Jira admin to register the webhook (ZopNight surfaces this as a "two-way sync needs setup" note).

Connect is effortless: ZopNight **auto-registers the inbound webhook** in Jira (with a manual-paste fallback if the token user isn't a Jira admin) and **de-registers it on disconnect**.

## Create a ticket from a recommendation

On any recommendation drawer, **Create Jira ticket** (admin-only) opens a dialog (optional project / issue type / assignee, defaults applied server-side) and opens a real Jira issue carrying the summary, the resource, the savings, the suggested fix, and a stable fingerprint label. You get a clickable issue badge linking straight to Jira.

Deduplication is per-problem on a stable `(org, resource, rule)` fingerprint, so it survives recommendation-id churn; the same finding never opens a second ticket.

## Automatic ticketing by policy

A recommendation policy carrying an **open-ticket** action opens a Jira ticket automatically whenever a matching finding is newly surfaced. You set this up as part of the connect flow; the last step of the Connect Jira drawer asks what to ticket:

**Set up later**

    Connect now, decide ticketing later. (Default.)

**All recommendations**

    One catch-all policy, with a live "≈ N open today" hint so you see the volume before saving.

**Specific recommendations**

    Route to the scoped policy creator with conditions, and a live "≈ N match" estimate.

Ticketing policies are managed in one place: **Settings → Policy**. The connected Jira card links straight to it. Auto-ticket delivery is at-least-once and bounded; it retries transient failures and gives up after a cap, so an outage can't loop.

## Two-way sync

**Status sync** keeps the recommendation and the Jira issue in agreement, event-driven (no polling):

| Recommendation state | Jira issue |
|---|---|
| closed / dismissed / optimised | → Done |
| applied / observing | → In Progress |
| drifted | → a comment on the issue |

A Jira status change flows back the other way through the webhook and moves the recommendation via its state machine (illegal transitions are dropped, never forced). A loop-guard prevents ping-pong, and a deleted Jira issue soft-deletes the link (the recommendation is untouched).

**Ownership sync**: set an owner on a recommendation and ZopNight re-assigns the *same* Jira issue (never mints a new one). A Jira assignee change flows back onto the recommendation's owner.

## Notes & limits

- **One effect per scope.** A single finding can carry either `notify` or `open-ticket` from one policy scope, not both; set them at different scopes if you want both.
- **ServiceNow** is not wired today, but the connector boundary is provider-neutral, so it's an add-a-connector change rather than a rebuild.