Jira Service Management
Connect a Jira Service Management (JSM) service desk so agents can read customer requests with their request type, SLA state and queue, ingest requests as alerts, and post internal investigation notes back onto the ticket.
JSM is a separate integration from Jira. They can point at the same Atlassian site with the same credentials, but they are separately licensed products and Autoheal keeps them apart — a Jira Software team never sees service-desk tooling, and a service desk gets the tools it actually needs. If you run both products, connect both; Autoheal routes each ticket to the right one automatically.
Capabilities
| Capability | Description |
|---|---|
| Requests | Read a request with its request type, SLA state, queue and comment history |
| Service desks | Discover service desks, their request types and customer organizations |
| Queues | List a desk's queues, or the requests currently sitting in one |
| Issues | Everything the Jira integration does — JQL search, transitions, comments |
| Alerts | Receive service-desk requests as alerts, grouped and investigated |
| On-call | Find who is on call, from JSM Operations |
| Write-back | Post investigation results as internal comments |
Write tools on this integration (create issues, add comments, assign and transition issues) are available only to agents granted write access to it. A governance policy on write operations pauses each write for a person to approve, and every call is recorded in the Audit Trail.
Supported platforms
| Platform | Authentication | Service desk | Operations |
|---|---|---|---|
| Atlassian Cloud | Email + API Token | Yes | Premium / Enterprise only |
| Data Center | Personal Access Token | Yes | Not available |
Setup
Cloud: create an API token at Atlassian API Tokens.
Data Center: create a Personal Access Token under Profile → Personal Access Tokens.
The account must be a service desk agent on the desks Autoheal should read.
- Go to Integrations and click Add Integration
- Select Jira Service Management
- Enter your site URL and credential
- Click Save, then Test connection
Test connection reports which capabilities this instance actually exposes — whether the service desk API is reachable, and whether Operations is available. Use it first if anything looks missing.
What agents can read
A JSM request is also a Jira issue, so JQL search, issue reads and comment history work on it exactly as they do for any other issue. That is what makes historical requests readable in bulk, comment history included.
Four things are not on the issue and need the service-desk API:
| What | Why it is not on the issue |
|---|---|
| Request type | A custom field whose id differs per instance |
| SLA state | Custom fields carrying the running / paused / breached clocks |
| Queue | A queue is a saved filter, not a field on the issue |
| Approvals, organizations | Separate service-desk resources |
Comment visibility
Every comment Autoheal posts to a request — investigation updates, hypotheses, root-cause summaries, and any ad-hoc note an agent adds — is internal: visible to service desk agents, never to the customer in the portal.
This is not configurable, by design. Autoheal is not a participant in your customer portal, so there is no path by which its commentary reaches the person who raised the request.
Investigation status updates (started, hypotheses, root-cause summaries) are posted by the platform rather than by an agent tool call, so approval policies don't apply to them.
Alerts from requests
Requests ingest as Autoheal alerts through the standard Jira webhook.
Go to Integrations → Jira Service Management → Settings, enable webhooks, and copy the URL.
Cloud: Settings → System → Webhooks. Data Center: Administration → System → Webhooks.
Select Issue created and Issue updated. There is no JSM-specific webhook event — a request raised through the portal fires the standard issue events.
Recommended: add a JQL filter scoping it to your service desk projects. Autoheal only ingests service-desk projects on this integration and drops the rest, but a filter avoids sending traffic it will discard.
Where the payload carries them, alerts also record:
jsm_request_type— so incident request types can route differently from ordinary service requestsjsm_sla_breached— so breached requests can be filtered and routed
Both appear as filters on the Alerts page, alongside a Request type and SLA column.
Two caveats worth knowing:
- Jira omits the request type and SLA fields from the webhook unless the user whose action fired it is a service desk agent or project administrator. The alert is still created with everything else; only these two extras are missing, and agents can always read them from the request itself.
- SLA breach is not a native Jira webhook event. To alert on a breach, add a JSM automation rule that edits the request when its SLA breaches.
Running Jira and JSM together
If both integrations are connected to the same Atlassian site, Autoheal routes each ticket to the right one using the project type — service-desk projects to this integration, everything else to Jira. Nothing is ingested twice, and no JQL is required to keep them apart.
Priorities
ITSM priority schemes map to Autoheal severities:
| Jira priority | Severity |
|---|---|
P1, 1 - Critical, Highest | Critical |
P2, 2 - High, High | High |
P3, 3 - Moderate, Medium | Medium |
P4, P5, Low, Lowest | Low |
Operations (on-call and alerting)
JSM Operations is the alerting and on-call product that replaced Opsgenie. Autoheal reads it for ownership context — who is on call, who was paged, who acknowledged — which nothing else in an investigation can answer for a JSM shop.
Requires Atlassian Cloud with a Premium or Enterprise plan. It does not exist on Data Center. Where it is unavailable the Operations tools say so clearly rather than failing obscurely, and the rest of the integration is unaffected.
Autoheal does not use Operations as a paging engine and never acknowledges or closes anyone's alert — it reads only.
Self-hosted and BYOC
Jira Service Management Data Center works with the Data Center (PAT) auth type.
- BYOC. No extra configuration — Autoheal runs inside your deployment and reaches JSM over your own network, including an instance with no public ingress.
- SaaS. Your instance must be reachable from the internet; allowlist Autoheal's egress if it sits behind a firewall. Note that alert ingest works either way — Jira posts outbound to your webhook URL, so an internal instance can still raise alerts even when Autoheal cannot call into it.
- An instance with no public ingress, on SaaS, is not supported today. Talk to us — BYOC is the supported answer for that shape.
Permissions
The API token or PAT needs:
- Browse Projects — view projects and requests
- Add Comments — post investigation results
- Transition Issues — change request status (optional)
- Service desk agent on the desks Autoheal should read. Without it the service-desk tools return a permissions error, and Jira omits the request-type and SLA fields from webhooks.
For Operations, the credential additionally needs the Operations read scopes and the site needs a Premium or Enterprise plan.