Technical Anshu
Tutorials Blog
🔄 Jira Sync Guide

Jira ServiceDesk Plus Sync Stopped Working Token and Permission Checklist

Integrations rarely die dramatically. They die quietly, on a Tuesday, because a token expired or somebody tidied up permissions. The tickets keep arriving, the statuses stop moving, and nobody notices until a user asks why their fix "has not started" while developers finished it last week.

✍️ Technical Anshu🎫 ServiceDesk Plus + Jira⏱️ 7 minute read
🎥 Watch the full setup in the video — every click, step by step

Work this list in order — it runs from the causes that break nine out of ten syncs to the exotic ones. The pattern to internalise: a sync between Jira and ServiceDesk Plus is a chain of account, token, permission, connection and mapping, and it fails at exactly one link. Your job is to find which link, not to reinstall anything.

Sync health — the chain, link by link
Sync account still exists and can log inOK
API token valid (not expired or revoked)BROKEN
Account still has access to the Jira projectOK
Connection test from ServiceDesk PlusNOT RUN YET
Last successful syncToken expiry date
Nine times out of ten the chain breaks at the token. Check it before touching any mapping. Example panel, shown as an illustration.
1

Link 1 — the Token (Check This First, Always)

  1. Jira Cloud API tokens expire (Atlassian moved tokens to set lifetimes) and can be revoked by the account owner or an org admin cleaning up.
  2. The signature symptom: sync worked until a specific date and stopped for everything at once, with errors mentioning authentication — a 401 or "unauthorised" in the logs.
  3. Fix: create a fresh API token in the sync account, paste it into the integration settings, run the connection test, then re-link or retry a test ticket.
  4. While you are there, put the new expiry date in a calendar with a reminder a week early. Token expiry should be a scheduled errand, never a surprise outage.
2

Link 2 — the Account and Its Permissions

  1. Did the sync account get disabled — for example when the employee who created it left? Sync accounts tied to a person die with their offboarding.
  2. Did it lose project access in Jira, or its technician role in ServiceDesk Plus, during a permissions tidy-up?
  3. Log in as the sync account and try to open the Jira project and create a test issue by hand. If the account cannot do it manually, the sync cannot do it either — and the error message will finally be honest.
3

Link 3 — the Connection Itself

  1. URL changed? Jira site renamed, server migrated, or ServiceDesk Plus moved between cloud and on-prem — the integration still points at the old address.
  2. Network changed? New firewall rules, a proxy, or IP restrictions can silently block the calls, especially for on-prem systems.
  3. Something upgraded? A Jira or ServiceDesk Plus update can change APIs or reset an app. After any upgrade on either side, run one test ticket through the full journey before trusting the sync.
4

Link 4 — the Scope (Sync Works, but Not for This Ticket)

If some tickets sync and others do not, the chain is fine and the map is the problem:

  1. The ticket was never linked — unlinked records do not sync, whatever the health of everything else.
  2. The Jira issue sits in a project outside the configured scope, or the project was renamed or archived.
  3. A new status or issue type appeared that the mapping has never heard of — it has nowhere to go, so it goes nowhere.
5

Secure the Sync Account So It Stops Breaking (and Cannot Hurt You)

Most sync fragility and most sync risk have the same root: the account was set up casually. Set it up like infrastructure:

  1. Dedicated, non-human account — its existence does not depend on any employee staying.
  2. Least privilege — only the Jira projects and ServiceDesk Plus scope the sync touches. A sync account that can administer everything is a breach waiting for a token leak.
  3. Token in the vault, expiry in the calendar — never in a spreadsheet, a wiki page, or a chat message.
  4. Quarterly five-minute audit — can it still log in, is the token healthy, does it still have exactly the access it needs and no more?
  5. Rotation on change — when the integration's owner changes role, rotate the token as part of the handover.
🔴 Write the fix down in the ticket system itself. The next silent death is coming; the person on call at that moment deserves your checklist, not your memory. A one-page runbook inside ServiceDesk Plus turns a half-day mystery into a ten-minute errand.

🎥 Watch the Complete Video

The full Jira and ManageEngine sync setup — live demo, step by step, in the video.

▶️ Watch Full Video
❓ Common Questions (FAQ)

How do I know if it is the token or something else

Token failures stop everything at once and leave authentication errors (like 401) in the integration logs, often starting exactly on the token expiry date. Permission and mapping problems are partial — some projects or tickets sync while others do not. Total silence points to the token or account; partial silence points to scope.

Should the sync use my admin account to avoid permission problems

No — it feels convenient and is the most common cause of both outages and risk. When you change your password or leave, the sync dies; and a leaked personal token is an admin token. A dedicated, least-privilege account with a calendar reminder for its token is both sturdier and safer.

After fixing the token, will missed updates catch up

Comments and statuses added while the sync was down do not always backfill automatically. After reconnecting, spot-check the tickets touched during the outage and copy across anything important by hand — then note the gap dates in the tickets so nobody later mistakes silence for inactivity.

This guide is based on the Technical Anshu video on syncing Jira with ManageEngine • Stuck on a step? Ask in the video comments — answers happen there 🙏