Adding an AI Agent on Top of Your Existing ITSM

Keep the ITSM you have, whether Jira Service Management, Freshservice or Zendesk, as the system of record, and put the agent where employees already ask. Then choose between two forms: the platform’s own agent, or a separate agent that creates and syncs linked tickets. Before deployment, settle the credentials the integration uses, what the agent may create in the ITSM, and how the two sides synchronize. The decisions come in an order: what the ITSM keeps doing, which account the integration uses, what the agent may create, and when resolution moves. How a resolution carries over from one tool to the other differs between products and is not always documented consistently, so test it on one escalation before relying on it. Examples of each form follow: Atlassian and Freshworks for the platform’s own agent, Harmony, Ravenna and Serval for a separate one.

Native agent or separate agent: what changes for the ITSM?

The two forms differ in where the employee’s request lives. With the platform’s own agent there is one record. Atlassian’s post describes requests moved “from disparate channels into one Slack channel that was tied to a Jira customer portal”, then a virtual agent that serves knowledge base articles in Slack and hands complex tickets to “a real service desk agent monitoring a queue”. Freshworks documents Freddy AI Agent, in a support article filed under “Freddy AI Agent (Classic)”, for Slack, Microsoft Teams, email and the portal on its Enterprise plan, and meters it: on the same Classic page, each Freshservice Enterprise license includes 1,200 Freddy AI Agent sessions a year, a session being counted when a unique user interacts with the agent within a 24-hour period.

With a separate agent there are two records, the agent’s request and the ITSM ticket, linked, and each vendor decides differently what crosses the link. Ravenna enables replication to Freshservice channel by channel, inbound and outbound separately. Harmony’s Jira Service Management page offers a Bidirectional Sync toggle that enables or disables outbound sync. Serval’s Jira page asks for a sync strategy, with status and priority mappings per project. A two-way sync is therefore a set of choices, not a switch.

The published numbers need reading before the steps. In the post dated 1 February 2023, Atlassian IT writes that its virtual agent “provided assistance with over 50% of all incoming requests, either resolving the issue or gathering more context for a human support agent”, and that it “fully resolved over 10% of all requests”. The post also gives 500 hours saved in the first month, and calls the feature “in its infancy”. Those are two measures of one vendor’s own deployment, more than three years old, and neither is a deflection rate. The only number that transfers to your queue is the one your queue produces.

Four decisions, taken in this order

The order below is a reading of what the sources document, not a measured sequence. It applies to either form, though the first decision weighs most when there are two records.

The first decision is whether Jira Service Management, Freshservice or Zendesk carries on creating, routing and closing tickets while the conversation moves to Slack, Teams or a portal. If it does, it stays the system of record, and the next question is which events cross, in which direction, and with what default.

The documentation read for this page answers that at three different grains. Serval sets the direction for new tickets only (“Sync Out”, “Sync In” or “Two-way Sync”), while updates to tickets already linked sync both ways, per its Sync Scope toggles. Ravenna enables inbound and outbound replication separately for each channel, and applies a fixed status mapping to Freshservice, in which its “Done” group becomes Resolved. Siit’s ticketing page goes down to the event: for resolved, assignee, note and new message, an administrator picks a behavior in each direction.

Defaults decide what the employee sees. Where a resolved ticket does nothing to the request by default, the employee’s thread stays open until someone closes it; where statuses map automatically, a wrong mapping closes requests that are not done. Either way, test one escalated request per platform, direction by direction.

Atlassian, Zendesk and Freshworks each document a ceiling, in different vocabularies, and in each the user’s role or permissions are part of it, not a scope list alone.

For OAuth 2.0 (3LO) apps, Atlassian states that “the permissions held by the user an app is acting for always constrain the app, regardless of the app’s scopes”, with an example: an app holding the manage:jira-project scope is unable to create projects if the user lacks the Administer Jira permission. Effective access is the intersection of what was granted and what the user can do.

Zendesk documents two token types. An API token is not tied to one person: each request supplies a user’s email address and runs with that user’s role. An OAuth access token is limited by its scopes, the user’s role, and the allowed scopes an administrator configured on the OAuth client. Zendesk’s API reference, which labels the API token “deprecated”, warns that “as passwords, API tokens can be used to impersonate anyone in the account, including admins”, and says that existing customers using basic authentication or API tokens “will have to migrate to OAuth access tokens”.

Freshworks documents a personal API key found on the agent’s profile settings page, and states that ability to access data “depends on the permissions available” for that profile, with the example of an agent role that may view tickets but not answer them. The same documentation says Freshservice APIs support OAuth, with the required scopes given against each API.

Two operational facts follow. For OAuth 2.0 (3LO) apps, Atlassian notes that an administrator is unable to revoke a user’s access to an app from the Connected Apps screen and can only uninstall the app, which would matter if an integration were authorized by a named employee. And Freshservice applies its API rate limit per account, across all agents and addresses, from 100 calls a minute on Starter to 500 on Enterprise (for accounts created since September 2020), with paid add-ons, for Pro and Enterprise only, that raise the overall limit from 500 to 1,000 and from 1,000 to 2,000 requests a minute.

The agent vendors’ pages read here do not settle on one account model. Siit’s page advises a dedicated service account where possible, such as a Jira user named for the integration, because the integration “inherits that account’s permissions, and a service account survives admin turnover”. Ravenna’s Freshservice replication runs through a dedicated OAuth agent, whose changes “are ignored to prevent sync loops”. Harmony asks to sign in with an Atlassian account that has admin permissions, then checks, for each Jira Service Management project selected, whether the integration user holds permissions such as Browse Projects, Transition Issues and Assign Issues, and shows the gaps before go-live. Serval’s Jira page says that Jira calls “run as the user who connected the integration unless a workflow opts in”, which on a connection upgraded by its Forge app switches to a service account. The per-platform detail lives on Jira Service Management, Freshservice and Zendesk.

Where the agent can write is a decision about the ITSM, not about the agent. Three settings recur. The destination: Serval’s Jira setup asks for a default project, a request type for a Service Management project, and the required fields for that destination; Harmony flags a Jira Service Management form as unavailable when a required Jira field is missing from it, so that incomplete tickets are not submitted. The owner: when an AI-owned Jira issue escalates and syncs out, Serval assigns it to its own app account by default, unless “Leave AI-owned tickets unassigned” is turned on. The approval: Siit’s ticketing page lists /jira create issue and /zendesk create ticket for its IT Agent, each with “approval available”, and frames approval gates as the control “for anything sensitive”.

For Freshservice, the integration overview and the Freshservice page of Siit’s documentation give conflicting indications: the overview’s table shows a dash in its “Available in IT Agent” row, while the Freshservice page says /Freshservice create ticket is available inside IT Agent playbooks. Confirm in your workspace.

The checklists end the same way: Siit’s page advises starting with one project or queue and escalating a sample request, Ravenna’s asks for a test ticket in the channel. What an agent may do alone has its own page, listed under related reading.

Running in front produces a first measurement on a queue the team already has, in two columns, as the Atlassian post shows: assisted and resolved. Moving resolution out of the ITSM also depends on what crosses: an automation that closes the employee’s request when the linked ticket closes is only as reliable as the status sync behind it, which is why decision one comes first.

• 01

  Decide what stays the system of record

  The first choice is not the connector. It is whether the incumbent keeps creating, routing and closing tickets, and which events cross between the agent's record and the ticket, in which direction.

• 02

  Connect through an account you can review

  Atlassian, Zendesk and Freshworks each document that a user's role or permissions limit what an integration acting for that user can reach. A named person's account carries those rights.

• 03

  Set what the agent may create before it does

  Map the default project or queue, the request type and the required fields, start with one destination, and test one escalation before an agent creates tickets on its own.

• 04

  Move resolution across last, or not at all

  Running in front produces the numbers that make the second decision informed: resolved, assisted, and what reached the ITSM with usable context.

What running in front leaves out

Attachments. Ravenna’s Freshservice replication page lists attachments among what is “Not synced”. Serval’s Jira page says a file synced from Jira lands on the Serval message of the comment it was attached to. Harmony uploads file attachments in Jira Service Management forms and links them to the created request. Siit’s ticketing page does not say whether attachments or the agent’s decision trace travel with the ticket.

History. Ravenna lists “Ticket history and audit logs” as not synced. Serval points to a CSV ticket import page for “a one-time import of Jira history with no live connection”. Siit’s ticketing page covers escalation and sync of linked tickets and does not describe importing historical tickets. A team that wants past tickets in the agent’s view should ask for the import path rather than assume the sync covers it.

Adding an agent and migrating off Jira Service Management are two decisions

The sync pages read for this guide describe escalation into the existing tool, where the ticket is created and linked. Migrating is a separate decision, and the sources cited here do not present one as a consequence of the other.

A migration case can be argued on criteria a team can check: whether ticket history can be imported, which processes the destination supports (change, problem, configuration data), what its API rate limits are, and how its integrations authenticate. A migration considered before the first three decisions are settled is decided without what they would have measured.

Which vendors document linked tickets in an installed ITSM?

Listed here: vendors whose public documentation, read for this page, shows the agent’s platform creating a linked ticket in Jira Service Management, Freshservice or Zendesk, by escalation, export or replication, with a sync an administrator configures by direction, scope or event.

• Harmony: its Jira Service Management page describes exporting a Harmony ticket to Jira Service Management as a native service desk request, and a Bidirectional Sync toggle that enables or disables outbound sync.
• Ravenna: its Freshservice ticket replication page lets an administrator enable inbound and/or outbound replication per channel, with Freshservice tickets created from new Ravenna tickets.
• Serval: its Jira page offers Sync Out, Sync In or Two-way Sync for new tickets, with status and priority mappings per project, and labels Service Management projects JSM.
• Siit: its ticketing page lists Jira Service Management, Zendesk and Freshservice among supported tools, with escalation from a request into a linked ticket and a behavior chosen per direction for each sync event.