Jira (ITSM)
Turn recommendations into Jira tickets; manually, or automatically by policy; with two-way status and ownership sync.
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; 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.
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
notifyoropen-ticketfrom 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.