Jira Service Management
Open a request, issue or Operations alert in Jira Service Management for every Event, comment on updates and close it when the Event resolves.
v1Updated
The Jira Service Management integration turns Events into work your service team already tracks. It works with Jira Cloud and Jira Data Center and has two delivery modes. Connect it under Integrations, Incident management, then add a notification channel for it so your Watches’ notification policies can use it. Send to integration on an Event works with it too.
Delivery modes
| Mode | When the Event opens | On an update | When the Event resolves |
|---|---|---|---|
| Requests and issues | Creates a customer request (service desk and request type) or a plain issue (project and issue type) | Adds a comment; on a customer request it is an internal comment | Performs the resolve transition, then comments |
| Operations alerts | Creates an alert with the Event id as its alias | Adds a note | Closes the alert |
Operations alerts are available on Jira Cloud only.
What a ticket contains
The summary is the Event title. The description has the Event summary, the explanation of what failed and what still works when one exists, the failure boundary, journey, Watch, environment, severity, kind, opened time and location, a link back to the Event in ScoutSentinel and links to its evidence. Jira Cloud receives it in Atlassian Document Format; Data Center and customer requests receive plain text.
Every ticket gets the labels scoutsentinel and scoutsentinel-event-<event id>, the priority mapped from the Event severity, and any labels and components you configure. If the create screen of your project does not include the priority or component field, the ticket is created without them rather than not at all.
Retries never duplicate tickets
Deliveries are at-least-once. Before creating anything ScoutSentinel looks for an issue with the scoutsentinel-event-<event id> label, and the issue key is stored on the delivery so later comments and the resolve go straight to it. Operations alerts de-duplicate on Atlassian’s side through the alias. The delivery log under Integrations, Deliveries shows the issue key as a link to your site.
A delivery failure never changes the Event. Retryable failures (rate limits, 5xx, timeouts) back off and are retried; credential and configuration errors stop immediately with a clear message, and you can retry them from the delivery log once fixed.
Connect Jira Cloud
- Create an API token for the Atlassian account the integration should act as. A dedicated account makes the ticket history easier to read.
- Give that account permission to create issues, add comments, edit issues (for the labels) and transition issues in the project. For customer requests it must be an agent of the service desk.
- In ScoutSentinel enter the site URL (
https://your-site.atlassian.net), the account email and the API token. - Choose where tickets go: a service desk id with a request type, or a project key with an issue type.
- Connect, open Edit and choose Test connection. The test checks the credentials with
GET /rest/api/3/myself, checks that the project or service desk and the request type exist, and loads the request types, priorities and transitions so you can pick valid values. It creates nothing in Jira.
The service desk id is the number in the portal URL, /servicedesk/customer/portal/<id>.
Connect Jira Data Center
Choose Jira Data Center, enter the base URL of your instance and a personal access token, which is sent as a bearer token. The instance must be reachable from the internet over HTTPS; private and loopback addresses are refused. Data Center uses REST API v2 and plain text descriptions.
Connect Operations alerts
In Jira Service Management open Operations, add an API integration for the team that should receive the alerts and copy its API key. Choose Operations alerts in ScoutSentinel and paste the key. Optionally name the team to route to and map severities to P1 through P5.
The test for this mode sends a P5 test alert and closes it straight away, because the alert API has nothing to read.
Settings
| Setting | Default |
|---|---|
| Resolve transition | Resolve this issue, then Done, then any transition that leads to a status in the done category |
| Severity to priority | critical Highest, high High, medium Medium, low Low, info Lowest |
| Severity to alert priority | critical P1, high P2, medium P3, low P4, info P5 |
| Labels, components | None beyond the two labels that are always added |
Tokens and keys are stored encrypted and never shown again. Leave a token blank when editing to keep the stored one.
Errors
| Message | What to check |
|---|---|
| Jira rejected the credentials (401) | The account email and API token, or the personal access token |
| The Jira account lacks a required permission (403) | Create, comment, edit and transition permissions in the project |
| Jira could not find the project, service desk, request type or issue (404) | The project key, service desk id and request type id |
| Jira rejected the request fields, followed by field names | A required field of your request type or create screen that ScoutSentinel does not fill. Make it optional or choose another request type |
| No transition to a done status is available | The workflow has no transition from the ticket’s current status to a done status. Set the resolve transition by name |
Not yet supported
Changes made in Jira are not synced back: resolving a ticket in Jira does not resolve the Event. ScoutSentinel resolves Events from its own observations.