Jira Integration Requirements¶

What has to exist on the Jira side before the integration can be connected, and what the account Qualytics authenticates as needs to be able to do.

The Jira Instance¶

Requirement	Details
Jira Cloud	The integration talks to the Jira Cloud REST API. A Jira Data Center or Server instance is not supported.
Instance URL	The full site URL, in the form `https://your-domain.atlassian.net`, with no trailing slash.
API access	The REST API has to be reachable from the deployment. A self-hosted Qualytics behind a firewall needs outbound access to the Jira site.
Projects	At least one project the integration may create issues in. You pick them while connecting, from the list Qualytics reads out of Jira. Software, business, and Jira Service Management projects can all be used.

The Integration Account¶

Qualytics authenticates as one Jira account and acts on its behalf: every issue it creates, every comment it posts, and every transition it runs is attributed to that account. A dedicated service account is easier to recognize in the issue history than a person's own login.

Value	Details
Email	The email address of the Atlassian account.
API token	A token generated from that account's Atlassian settings. See Jira Configuration.
Format	The two are entered together as `email:api_token`, which is what the Credentials field expects.

Changing the account later

The credentials can be replaced at any time from the edit modal, and issues created by the previous account keep their history. See Edit Jira Connection.

Permissions in Jira¶

The account needs permission in every project you allow, not only the default one. The full list, and what each permission is for, is on the Permissions page.

Registering the webhook is the one step that asks for more than the integration account. Webhooks live in Jira's system settings, so a Jira administrator creates it. See Register the Jira Webhook.

Jira Service Management Projects¶

A Jira Service Management service project can be an allowed project. Its requests are ordinary Jira issues, so creating, linking, searching, status sync, and comments work as they do on any other project, with three differences.

Difference	Details
The account needs an agent seat	In a service project, Jira lets only licensed agents create issues through the API. Portal customers hold the Create Issues permission too, so that permission alone is not enough. An Atlassian administrator gives the integration account Jira Service Management agent access, and a project administrator adds the account to the service project as an agent. Without that, the project's Issue Type field shows `You cannot create issues in this project` with a reminder about the agent seat, and creating a ticket there fails.
Pick a service issue type	A default service project has no `Task` type, so set the project's Issue Type to one it has, such as Service request or Incident. A type that needs approval, such as Service request with approvals, creates the issue in its waiting-for-approval status, as it would for any agent.
Comments are internal notes	Every comment Qualytics posts on a service project issue is an internal note: mirrored comments, their edits, and status notes alike. Agents see them on the issue, and customers do not see them in the portal. See Comments on Jira Service Management Projects.

Issues created by Qualytics stay out of the portal

Qualytics creates the issue without a request type, so it is not listed in the customer portal. Agents see it in the project like any other issue.