Skip to content

Jira Service Management

Jira Service Management brings the tickets your customers raise into Sonora, next to their calls, emails, and CRM data. Each ticket becomes a customer issue with a summary, gets an eCSAT score, and appears on the customer’s timeline. Home counts it as open until Jira moves it to a done status.

Jira is in early access: your Sonora team connects it for you.

  • Tickets from one Jira project: summary, description, status, priority, reporter, JSM organizations, and created, updated, and resolved dates
  • Comments on each ticket, public and internal

The integration is read-only. Sonora never creates, edits, or comments on tickets.

Internal comments stay internal. Summaries and eCSAT read only the description and public comments, and the issue panel shows only public comments.

Jira’s default priorities map onto Sonora’s: Highest is urgent, High is high, Medium is medium, and Low and Lowest are low. A custom priority keeps its own name.

Sonora attaches each ticket to one customer, using the first rule that gives an answer:

  1. The ticket’s JSM organizations, matched to Sonora customers by name. Sonora accepts only a close match, and if two organizations on one ticket name different customers, it matches neither.
  2. The reporter’s email, when it belongs to a contact of exactly one Sonora customer.
  3. The domain of the reporter’s email.

A reporter on your own company’s domain, for example a CSM who files a ticket for a customer, matches no customer by email. Change the ticket’s reporter to the customer, or add their JSM organization.

A personal address, such as one on gmail.com, matches only when it belongs to a contact in Sonora, never by its domain. An automated sender, such as a no-reply or notifications address, never matches by its domain either: the domain names whoever sent the notification, not the customer.

A ticket that matches no customer stays in Sonora and is matched again on its next update in Jira.

Sonora writes a ticket’s summary again only when its title, description, or public comments change. A status, priority, or assignee change updates the ticket without a new summary.

  • A Jira Cloud site (https://<name>.atlassian.net). Jira Data Center and Server are not supported.
  • The key of the project to sync, for example PS for tickets numbered PS-123
  • An Atlassian account or service account with Browse projects permission on that project

A scoped API token needs these three scopes, all read-only:

Scope Backs
read:jira-user Confirming the account and reading its time zone
read:jira-work Searching tickets and reading their comments
read:servicedesk-request JSM organizations on each ticket

Sonora also accepts a classic API token, which has the permissions of the account it belongs to. A scoped token on a service account limits Sonora to the access it needs, so prefer it.

  1. Sign in to Atlassian as the account Sonora will use. A service account keeps access independent of any one person.
  2. Create an API token with scopes, choose Jira, and select the three scopes above.
  3. Set an expiry date and copy the token. Atlassian tokens expire within a year, so note the date.

During early access, your Sonora team enters the site URL, project key, account email, and token for you. Share the token through a one-time link from your password manager rather than email or chat.

Sonora checks that the token gets in before saving it. Your Sonora team also runs the connection test, which checks that the account can browse the project: a save alone doesn’t, and an account that can’t see the project syncs no tickets. Sonora stores the token encrypted. Once saved, it can’t be read back from Sonora’s settings, which show only its last four characters.

The first sync imports the last 90 days of tickets. After that, Sonora syncs once a day and reads only tickets that changed.

Changing the project or the site starts the import over, so the new project’s history comes in. Sonora refuses the change while a sync is running. Changing the account email or the site requires the token again.

During early access, ask your Sonora contact to disconnect Jira. To revoke access on Atlassian’s side, delete the API token from the account’s security settings.

“… doesn’t answer as a Jira Cloud site. Check the address.”: the site URL is not a Jira Cloud site. Use the address you open Jira at, like https://acme.atlassian.net.

“Jira rejected the email or API token.”: the email is not the account the token belongs to, or the token was copied incompletely, deleted, or has expired.

“Jira accepted the token but it lacks a scope Sonora needs.”: the token is missing one of the three scopes above. Create a new token with all three.

“The account can’t see project …”: give the account Browse projects on the project, then test again.

“Jira has no project … on this site.”: the project key is wrong, or the project is on another Jira site. The key is the prefix of the ticket numbers.

“Couldn’t reach … Try again in a minute.”: Atlassian didn’t answer in time. Test again shortly.

A ticket has no customer: check the ticket’s JSM organizations, and that a Sonora customer has a close name match. If the ticket has no organization, the reporter’s email must belong to a contact or a customer domain in Sonora. A personal or no-reply address matches only as a contact. Atlassian hides the email of accounts whose profile visibility is private, and Sonora can’t match a hidden email.

A deleted ticket is still in Sonora: Sonora does not remove tickets that are deleted in Jira.