Map Ticket Fields Between ServiceDesk Plus and Jira the Honest Way
Field mapping is where sync projects quietly succeed or quietly rot. Map too little and the other team sees nothing useful. Map everything blindly and the two systems start overwriting each other's truth. This is the middle path that survives contact with real tickets.
✍️ Technical Anshu🎫 ServiceDesk Plus + Jira⏱️ 7 minute read
🎥 Watch the full setup in the video — every click, step by step
Open the two workflows side by side and the problem is obvious: the status lists were never designed to match. ServiceDesk Plus runs a service lifecycle — Open, In Progress, On Hold, Resolved, Closed. A Jira project runs a delivery lifecycle — To Do, In Progress, Code Review, Testing, Done, plus whatever the team invented last quarter. A field map is not a translation table between equals; it is a set of decisions about what each side needs to know. Make those decisions on paper first.
Status map — what Jira states show as, on the support side
Jira To DoOpen
Jira In ProgressIn Progress
Jira Code ReviewIn Progress
Jira TestingIn Progress
Jira BlockedOn Hold
Jira DoneResolved — verify with user
Six Jira states become three things the requester understands. The middle detail stays visible in Jira for anyone who needs it. Example map, shown as an illustration.
1
Start with the Four Fields Everyone Watches
Whatever else you map, these carry 95 percent of the value:
Subject / Summary — created once, from the request into Jira. Do not let both sides edit it independently or the titles will drift apart within a week.
Status — mapped by the table method in the next card.
Priority — map deliberately: ServiceDesk Plus priorities speak SLA language, Jira priorities speak planning language. Highest in one is not automatically Highest in the other; agree the conversion in writing.
Assignee — display it on the support side so a technician can name the human working on the fix. Editing assignees across systems is where sync tools start fighting; display-first is safer.
2
The Status Map — Collapse the Middle, Protect the Ends
Use this pattern and adjust names to your own workflows:
Not started maps to not started. To Do → Open. No ambiguity allowed here.
All middle states collapse. In Progress, Code Review, Testing, In QA — the requester only needs "In Progress". The detail still exists in Jira for anyone curious.
Blocked is the exception worth mapping. If Jira has a Blocked state, map it to On Hold — it changes what support should tell the user.
Done never auto-closes silently. Map Done to Resolved, and let a technician confirm with the user before Closed. Software being "done" and the user's problem being gone are related, not identical.
3
Fields to Deliberately Leave Unmapped
A good map includes a "do not sync" list. Typical members:
Fields both sides edit freely — if two teams can change the same field, the sync has to pick a winner on every conflict, and both teams will feel robbed. Give each shared field one owner.
Sprint and release fields — meaningless on the support side; they only create noise in the ticket.
Free-text description, after creation — the description should be a snapshot of the problem as reported. New facts belong in comments, which sync cleanly.
4
Custom Fields — Possible Is Not the Same as Wise
Deeper sync tools can map custom fields between the platforms, and sometimes you genuinely need one — a customer name, a device ID, a store number that developers use to find the right data. The honest test for each custom field: who reads this on the other side, and what do they do differently because of it? If nobody can answer, the field is decoration and will become stale decoration. Map the two or three that pass the test; leave the other forty at home.
5
Test the Map with Five Ugly Tickets
Before go-live, push five deliberately nasty cases through the sync:
A ticket whose Jira issue gets reopened after Done — does the request wake up correctly?
A highest priority ticket — does the priority arrive as the agreed equivalent, not something milder?
A ticket linked to two Jira issues with different statuses — what does the requester see?
A Jira issue marked Blocked — does On Hold appear on the support side?
A ticket a technician closes by hand — does anything strange bounce back from Jira?
Fix what these five break, write the final map down where both teams can read it, and only then announce the sync.
🔴 One owner per field. Almost every "sync overwrote my update" story traces back to a field both sides could edit. Direction is a feature: decide who owns each field and let the other side read it.
🎥 Watch the Complete Video
The full Jira and ManageEngine sync setup — live demo, step by step, in the video.
What happens when Jira has a status ServiceDesk Plus does not have
You map it to the closest support-side meaning — usually In Progress for any active middle state. The requester sees simple, truthful progress while the detailed state remains visible in Jira itself. Never invent a new support status just to mirror a Jira state.
Should priority sync both ways
Priority is a promise on the support side (it drives SLAs) and a planning signal on the dev side. A safe default is to set it at creation from the request, show changes from Jira as information, and let the technician decide whether the SLA promise changes. Silent two-way priority sync causes nasty surprises.
Can custom fields be mapped too
Yes, with deeper sync tooling many custom fields can be mapped, including text, dropdown and date fields. The limit is rarely technical — it is usefulness. Map only fields the receiving team actually reads and acts on, and give each one a single editing owner.
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 🙏