How to Add an AI Agent on Top of Jira Service Management

There are two ways to add an AI agent on top of Jira Service Management without replacing it. The first stays inside Atlassian: the JSM virtual service agent answers from a linked knowledge base or runs conversation flows in channels that include Slack or Microsoft Teams, and Rovo agents can raise JSM requests through a dedicated Create Request skill. The second is a third-party AI agent for Jira Service Management: Harmony, Ravenna and Serval document a connection through Atlassian’s OAuth 2.0 (3LO) consent flow, Moveworks a Jira service account with an API token. Three choices then decide how it behaves: which Atlassian account authorizes it, which way tickets travel, and which events, comments and fields sync back. Atlassian sets one rule for all of them: an app can do no more than the user it acts for, a service account included. JSM keeps its request types and queues in both cases. Attachments, history and internal comments vary by connector; test them on one service project first.

What does Atlassian’s own AI do inside JSM?

Atlassian documents two native agents, and neither needs a third-party grant.

The virtual service agent works in Microsoft Teams or Slack, “not both”, per Atlassian’s Slack setup page, which also lists email, portal, help center and widget channels. In Slack it “uses machine learning to recognize questions and requests” and can run turn-by-turn conversation flows, AI connected to a knowledge base, or a combination of both. Setting it up takes a project admin, an agent channel for agents and admins, and one or more request channels. Customers in those request channels need access to the JSM project before the agent can respond to them. Which knowledge sources such an agent answers from is covered in Confluence and the other knowledge sources.

Rovo agents add request creation in conversation. Atlassian’s Create Request skill lets a Rovo agent “gather information from a help seeker and create requests in Jira Service Management spaces”, reading the fields configured on each request type at runtime. Some field types, including attachments, Assets and components, are not collected conversationally; for those, the skill hands the help seeker a link to a pre-populated request form. The ticket receives a summary of the conversation, and a full transcript in Slack only. The skill requires Rovo and JSM Cloud.

What does a third-party connection need from Atlassian?

For integrations that are not Forge or Connect apps, Atlassian’s JSM REST API documentation points to OAuth 2.0 authorization code grants, known as 3LO, with calls sent to api.atlassian.com/ex/jira/<cloudId>/rest/servicedeskapi/. The user grants or denies access on an Atlassian consent screen, and the external service then exchanges an authorization code for an access token that works until it expires or is revoked. Grants are either account-level, covering several sites, or resource-level, limited to the sites selected on the consent screen. For “personal scripts, bots, and ad-hoc execution” the REST page points to basic authentication, which Moveworks uses with a Jira service account’s API token.

Two points matter. Scopes are not the whole boundary: “the permissions held by the user an app is acting for always constrain the app, regardless of the app’s scopes”. Atlassian’s example is an app holding the manage:jira-project scope that cannot create projects because the user lacks the Administer Jira permission. And revocation has a specific route: “An admin can’t revoke a user’s access to an app through the Connected Apps user screen”, because the grant is between the app and the user; the admin’s option is to uninstall the app.

The same REST page notes that whether a customer can raise requests depends on the service desk type: public with sign-up, open to any user, or closed, where only users associated with the service desk can submit requests. An agent that raises requests for employees runs into the same rules. Ravenna’s troubleshooting shows the effect: a ticket opened for someone missing from the Atlassian user directory, or without permission to open issues in that project, is created with no reporter or requester.

Which account connects, and what bounds it?

Atlassian’s protocol speaks of a user granting access. The vendor pages decide which user.

Vendor	Who authorizes the connection	What the page adds about the account
Harmony	An Atlassian account with admin permissions	Permissions of the integration user are audited per project at setup
Ravenna	A dedicated standard Atlassian user with a seat, with admin access	Not an Atlassian managed service account, which “will not work with Ravenna”
Serval	Any Jira account with access to the site, for Sign in with Jira	Calls run as the connecting user unless the Forge app’s service account is used
Siit	A JSM admin or Jira site admin	An optional dedicated Jira user, “so the integration survives admin turnover”

The account matters because of Atlassian’s rule: the agent sees and does what that account may do, project by project. Siit’s troubleshooting says a service project is missing from the escalation picker when the connecting user lacks Browse Projects on it, and that only request types the connecting user can create are offered. Harmony checks Browse Projects, Add Comments, Edit Issues, Transition Issues, Assignable User and Assign Issues on each selected project, and warns when the OAuth user is missing from the JSM agent group (jira-servicemanagement-users, or the legacy jira-servicedesk-users). Ravenna lists the roles to grant for JSM: User (Agent) and User Access Admin in the user directory, Service Desk Team and Administrators in each service space; every ticket, comment or status change it makes appears under that account’s name.

Scopes are the other bound. Serval lets the person connecting switch off individual scopes within three presets (Issue Tracking, Service Management, Projects & Administration), and warns that adding a permission later means reconnecting, because “Atlassian issues tokens only for the scopes granted when the connection was made”. It also notes that its three health checks “can pass while ticket syncing still does nothing”: they test the OAuth credentials, not the sync.

What syncs between the agent and JSM, and in which direction?

The published connectors differ in where a ticket starts and what travels back.

Siit starts from the employee request. From the request side panel, a person picks a JSM service project and request type, and a linked ticket is created with the request context pre-filled; the same step exists as a Create JSM ticket workflow action, “with field mapping and approval gating where needed”. Sync is set in one table per direction, one row per event. Toward JSM: resolve on resolution, match the assignee, push notes, push new messages. Back from JSM: resolve the request, match the assignee, import comments, import notes. Every option is opt-in, and the page calls the choices “capability-aware”, which keeps a private note from surfacing as a public comment where the provider has no private-comment concept.

Harmony describes a bi-directional sync. Tickets raised in JSM appear in Harmony with summary, description, priority, reporter, status, comments and internal notes, assignee and queue, request type, and the custom fields configured on the portal form, refreshed every 5 minutes. Statuses and comments sync both ways, and a Bidirectional Sync toggle turns outbound sync on or off. Agents can also export a Harmony ticket to JSM as a service desk request, with form fields, file attachments and a “View in Harmony” link back, and a Custom Agent Builder block raises a JSM request on behalf of an employee by email address.

Ravenna sets replication per channel: each channel picks a Jira project, an issue type and a direction (Ravenna to Jira, Jira to Ravenna, or bidirectional), with statuses mapped once for all channels and a default sync interval of 5 minutes. Serval offers Sync Out, Sync In and Two-way Sync, and states that “the sync direction applies to new tickets only”: updates to an already synced ticket travel both ways in every mode. On a Sign in with Jira connection, Serval’s ticket sync also requires its Forge app in the Jira site.

The direction is the first choice to settle: an agent that creates JSM tickets from conversations, an inbox that ingests JSM tickets, or both. Either way the ticket that lands in JSM is categorised by its request type and worked from its queue, as before.

• 01

  Two bounds, not one

  Atlassian states that the permissions of the user an app acts for constrain the app regardless of its scopes. Access is the overlap of what was consented and what the user the app acts for may do.

• 02

  The account is part of the design

  Ravenna requires a dedicated Atlassian user with a seat, whose name appears on every action it takes in Jira. Serval runs calls as the connecting user unless its Forge app's service account is used.

• 03

  Two directions of travel

  Siit escalates an employee request into a JSM ticket and syncs back per event. Harmony brings JSM tickets in and syncs statuses and comments both ways, with outbound sync on a toggle. Ravenna and Serval offer one-way or two-way modes.

• 04

  JSM keeps its own agents

  Atlassian documents a virtual service agent for Slack or Microsoft Teams, not both, and a Create Request skill that lets Rovo agents raise JSM requests in conversation.

What should you test before relying on the connection?

Run each on one test service project first.

• Internal and public comments. Ravenna syncs its private notes as JSM internal comments and back, for JSM only. Serval keeps a file attached to an internal Jira comment as an internal note. Post one internal and one public comment and check where each lands.
• Requesters. Beyond Ravenna’s reporter rule above, Harmony cannot match JSM accounts to employees by email when email visibility is restricted in Atlassian settings, a condition its health check flags.
• Events and statuses. On Siit’s sync table, events set to “Do nothing” do not cascade. Ravenna and Serval map statuses to the Jira workflow, and Ravenna warns that a mapped status has to exist in the project’s workflow.
• Scope of inbound sync. Harmony’s custom JQL filters for inbound sync are rolled out incrementally and enabled through a Harmony representative.
• Write actions. Serval’s prebuilt Jira workflows, such as Create Jira Issue and Transition Jira Issue, ship with installer approval by default. How far an agent may act without a person is the subject of what autonomy means for an IT agent.
• Exit. Atlassian’s admin route to cut a user-granted app is uninstalling it, not the Connected Apps screen.

Putting an agent in front keeps JSM as the system of record; replacing JSM is a separate decision about the ticketing platform. The general method across JSM, Freshservice and Zendesk is in adding an agent without replacing your ITSM, and the difference between a tool that answers and one that acts in what an AI service desk agent is.

Which vendors document an AI agent connection to Jira Service Management?

Listed here: vendors whose public documentation describes how their AI agent connects to Jira Service Management and what the connection creates or syncs. The authorization is stated where the page gives it. Atlassian’s own agents are covered above; they are not a third-party connection.

• Harmony: its Jira Service Management page has an Atlassian admin authorize OAuth, syncs tickets, statuses and comments both ways with outbound sync on a toggle, and exports Harmony tickets to JSM on demand.
• Ravenna: its Jira setup page has a dedicated Atlassian user authorize the connection, and its ticket replication page syncs creation, comments, statuses and descriptions per channel, without attachments or history.
• Risotto: its Jira integration page says Risotto integrates with Jira Service Management, labels, categorizes and routes tickets there and logs every action as a Jira ticket update; the page does not specify the authentication method.
• Serval: its Jira page connects through Atlassian OAuth 2.0 (3LO) with selectable permission presets, Service Management among them, and syncs tickets out, in or both ways.
• Siit: its Jira Service Management page has a JSM or Jira site admin authorize the connection, escalates requests into JSM service projects, and sets sync per event and per direction.