Jira (ITSM)
Connect Jira to turn recommendations into Jira tickets, on demand or automatically by policy, and keep status and ownership in sync both ways.
Recommendations only save money once someone acts on them, and in most organisations “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: Jira connected with its default project and issue type (AI provider connections sit on the same page).
Before you start
- Admin role in ZopNight. Connecting Jira and creating a ticket from a recommendation are admin-only.
- Your Jira site URL, plus the project key and issue type new tickets should default to.
- A bot user in Jira (its email address) and an Atlassian API token for it. Either token kind works (see Token kinds); the connect call checks the token live and tells you if a permission is missing.
- For two-way sync without manual steps: a classic API token whose user is a Jira admin, so ZopNight can register the inbound webhook for you. Without it, outbound ticketing still works and ZopNight flags that two-way sync needs setup.
How it works
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 creates a Jira issue carrying the summary, the resource, the savings, the suggested fix, and a stable fingerprint label. The recommendation then shows an issue badge that links 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. When you save the policy, it also files tickets for the matching recommendations that are already open.
You set this up in the last step of the connect flow, which has one Automatic ticketing toggle, Open tickets automatically, off by default:
| Choice | What it does |
|---|---|
| Toggle off (default) | Connect now, decide ticketing later. |
| Toggle on | One catch-all policy that opens a ticket for every open recommendation, including the current backlog. A live ”≈ N open recommendations will get a ticket” hint shows the volume before you save. |
| Customise scope (shown when the toggle is on) | Routes to the scoped policy creator with conditions, and a live ”≈ N match” estimate. |
Ticketing policies are managed in one place: Governance → Policies → Alerting. See Alerting policies for the conditions you can set and how overlapping policies are resolved. 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 cause a retry 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 |
Observing means the change was applied and ZopNight is still watching for it to hold; drifted means an applied change did not persist (for example, a later Terraform apply reverted it). See Applied, and then verified.
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 reassigns the same Jira issue (never mints a new one). A Jira assignee change flows back onto the recommendation’s owner.
Connect Jira
Open Integrations
Go to Settings → Integrations (admin-only) and choose Jira.
Enter the connection details
Provide the base URL, project key, issue type, bot email, and API token. The token is encrypted at rest.
Verify
The connect call verifies the credential live before saving. A successful connect shows Connected ✓. A bad token, missing permission, or unreachable host returns a categorised error.
Choose what to ticket
The last step of the Connect Jira drawer asks which recommendations should open tickets automatically. See Automatic ticketing by policy.
On connect, 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.
Reference
Token kinds
| Token | How it connects | Two-way sync |
|---|---|---|
| Classic | Authenticates against your site URL directly. | Registered automatically when the token user is a Jira admin. |
| Scoped (granular) | Connects through the Atlassian API gateway automatically. | Outbound ticketing works immediately; inbound sync needs a classic token plus a Jira admin to register the webhook. ZopNight shows a “two-way sync needs setup” note. |
Permissions
| Action | Who can do it |
|---|---|
| Connect Jira | Admin |
| Create a Jira ticket from a recommendation | Admin |
| Register the inbound webhook automatically | The token’s Jira user must be a Jira admin |
Notes and limits
- One effect per scope. A single finding can carry either
notifyoropen-ticketfrom one policy scope, not both. To get both, set them at different scopes. - ServiceNow is not wired.
Troubleshooting
Connect fails with an error
The connect call checks the token against Jira before saving. The error says which category failed: a bad token, a missing permission, or an unreachable host. Fix that item and connect again.
Tickets open, but Jira changes do not flow back
Inbound sync needs the webhook registered in Jira. That happens automatically only with a classic token whose user is a Jira admin. With a scoped token, or a non-admin user, ZopNight shows “two-way sync needs setup”; register the webhook with the manual-paste fallback or reconnect with a classic admin token.
A ticket was created without an assignee
ZopNight matches the assignee by email. If no Jira user matches, the ticket is created unassigned with a warning.
Why there is only one ticket per finding
Deduplication is per problem. If the finding already has a ticket, ZopNight does not open a second one; use the issue badge on the recommendation to open the existing ticket.