IT support teams running ManageEngine ServiceDesk Plus often need to hand work off to developers and project teams operating in Jira. Without a proper sync between both tools, this handoff usually means copy-pasting ticket details, chasing status updates over Slack, and losing context somewhere in the middle.
A platform like Exalate fixes this by setting up a bidirectional connection between Jira and ServiceDesk Plus so tickets, comments, statuses, and custom fields flow automatically between both systems. It works across Jira Service Management, Jira Software, Jira Product Discovery, Jira Work Management, and Jira on-premise, plus Docker deployments for teams that need more control over hosting.
Exalate Ramp-up and Configuration Steps
Here is a quick rundown of how to spin up an integration between ServiceDesk Plus and Jira.
Create an Account or Log In to an Existing One
- Head over to the Exalate app.
- Sign up with Google SSO using your work email, or set up an account manually.
- Click Create an account and fill in your business email, first name, last name, and a strong password.
-
Confirm the password and click Create an account again to move forward.

- Verify your email: Open your inbox and find the verification email from New Exalate.Note: The verification link is valid for 2 hours only.
- Click the link in the email. You will be redirected to finish setting up your account.
- Log in to your Exalate console using your email and password.
Create a Connection Between Jira and ServiceDesk Plus
- Log in to your account.
-
Click Add Connections > Create New Connection.

- The connection wizard opens and walks you through a step-by-step process.
- To configure System A (Jira):
- Enter the system URL [https://example.atlassian.net].
- A console status check kicks off automatically.
- If the system is already registered, you will see a confirmation message and can skip authentication.
- If the system is new, authentication fields appear right away.
- To authenticate System A (Jira):
- Run through Jira Cloud OAuth authentication.
- Click Check Authentication and wait for validation. If you have multiple Jira sites, choose the one you want to use for this connection. Once it succeeds, the Next button becomes active.

- Click Next to move to System B.
- To configure System B (ServiceDesk Plus), follow the same flow as System A:
- Enter the system URL for your ServiceDesk Plus instance.
- Wait for the system type to be auto-detected.
- Provide your authentication credentials (API key for ServiceDesk Plus).
- Click Check Authentication to verify.
- Click Next to continue.

- Name your connection something unique and descriptive, like "Jira-SDP-ITOps". If the name is already taken, you will see an error asking you to pick a different one.
- Add a quick description so anyone looking at the connection later knows its purpose, such as "Sync escalated IT tickets between ServiceDesk Plus and Jira dev team."
- Click Next to review your setup.
- Look over the connection details. Confirm the name and description.
-
Click Create Connection to start the setup process.

- New Exalate registers your systems automatically and establishes the link. You will see real-time updates as it completes. Once it finishes, you will see a success message, and the connection status changes to "Ready to configure."
- After the connection is created, choose which projects to sync between both systems.
Note: If the system has no concept of a project, this modal will not show up.
Configure Your Bidirectional Jira to ServiceDesk Plus Connection
You have two ways to do this: Quick Sync and Edit & Test.

The Quick Sync option lets you sync one item right away between your Jira and ServiceDesk Plus instances.
- Under "Item sync monitor," enter the work item key and click Sync Now.
- To link 2 existing items, click Link with existing.

- Once the sync finishes, both items show up in a new window. You can also compare the changes side by side.
To use the Edit & Test Sync option, follow these steps.
- Find the connection in the Connections list.
- Click the connection name or the Edit button to open the configuration page.
- On the connection configuration page, you will see the current sync rules.
-
To make changes, create a new version or click Open latest draft. This way, you are not messing with the live configuration directly.

- Click the Edit button to open the editor:
- Edit sync rules using Aida (the outgoing script holds the values being sent from Jira to ServiceDesk Plus, while the incoming sync defines how values coming back from ServiceDesk Plus are mapped in Jira).
- Click Save Script to save the version or Start Test Run to test what you have set up.
-
Click Publish Version when you are ready to activate the configuration.

- Click the Switch Direction button to edit sync rules for the opposite flow (for instance, if you want to tweak the incoming script of Jira and the outgoing script of ServiceDesk Plus). This creates a new version or draft for that direction, which also needs review and publishing.
- All configuration versions for a connection sit under the Version dropdown below the connection name.
- Versions have these statuses:
- Active: The currently published configuration.
- Draft: An editable copy of the Active version.
- Archived: When a new version is published, the previous Active one gets archived. You can restore an archived version by selecting Restore version.
AI-Assisted Configuration with Aida
- Open your connection.
- Click Add new version (or open the latest draft).
-
Click Edit to enter the script editor.

- In the Aida input field, type your request in plain English.
- Click the send button (or press Enter).
- Aida will start drafting your script.
- Review the suggested changes. Green highlights mean new lines being added, red highlights mean lines being removed.
-
Click Insert to accept or Discard to reject.
For Outgoing scripts: Describe what data should leave your system. For example, "Don't sync internal notes and low priority tickets."
For Incoming scripts: Describe how incoming data should land in your system. For example, "Map technician to assignee".
Note: Aida is a great starting point, but always review the generated code before pushing it to production.
Test Run: Validate Before Production
Once your sync scripts look ready, click "Start Test Run" to validate them.
-
Pick the items you want to test (you can select multiple). Click Start Test Run to preview how the configuration will apply.

- Check the incoming and outgoing replicas for each test item. Make sure the field mappings look right. If something is off, go back, change the scripts, and run another test.
- Only deploy when you are confident everything works. Click Publish Version to apply the updated configuration to live sync.
Automate Jira ServiceDesk Plus Integration Using Triggers
Triggers decide which items sync automatically based on conditions you set.

- Click "+ Add trigger" to create a new one.
- Add trigger conditions using platform-specific syntax:
- Jira Query Language (JQL):
project = SUPPORT AND priority in (High, Highest). - ServiceDesk Plus query syntax:
status='Open' AND priority='High'
- Jira Query Language (JQL):
- Activate triggers by toggling them on. Save your changes by publishing.
Troubleshoot with Aida
- Open the "Troubleshooting" tab.
- Hover over any error and click the Aida icon for instant analysis. Aida shows affected systems, connections, and work items, plus a short explanation of what went wrong.
- For a deeper dive, click "Error Details" to see the impact level, stack trace, error type, and when it happened.

- Use "View Full Analysis" for full context. Once you have fixed the issue, click "Resolve" to clear the error.
Your integration is now live. Sync runs automatically based on the sync rules and triggers you have configured.
Advanced Jira and ServiceDesk Plus Integration Use Cases (Using Aida)
Exalate brings AI-powered ServiceDesk Plus integration with Jira through the scripting engine baked into the configuration panel.
It also comes with several Script Helpers to cut down the time you spend writing connections from scratch.
Here are some real use cases for ServiceDesk Plus integration with Jira, sourced from customer conversations and live deployments.
Use Case 1: Escalate Helpdesk Tickets from ServiceDesk Plus to Jira Developers
When a ticket needs developer attention, like a bug fix or a code promotion to SIT, the request has to land in Jira so the dev team can pick it up without anyone re-typing the details.
Set up an outgoing sync on the ServiceDesk Plus side that creates a Jira work item whenever a ticket gets the status "Escalated." On the Jira incoming side, map the ServiceDesk Plus subject, description, requester, and attachments to the right Jira fields.
A sample prompt to Aida could look like this:
"On the ServiceDesk Plus outgoing side, when a ticket has status 'Escalated', send the subject, description, requester, priority, and attachments to Jira. On the Jira incoming side, create a new Bug work item in the DEV project using these values."
Aida will draft the script for both sides. Review it, refine the prompt if needed, and then publish.
Use Case 2: Sync Status Bidirectionally Between Jira and ServiceDesk Plus
If you want the status of a Jira work item to show up in the matching ServiceDesk Plus ticket (and the other way around), you need a mapping rule so both sides line up.
For example, when the Jira status is To Do, the ServiceDesk Plus ticket reads Open. When Jira shows In Progress, ServiceDesk Plus reads In Progress as well. When Jira moves to Done, ServiceDesk Plus updates to Resolved.
Drop the mapping into Aida using a prompt like this:
"I want to map statuses between a Jira work item and a ServiceDesk Plus request so that 'To Do' becomes 'Open', 'In Progress' stays 'In Progress', and 'Done' becomes 'Resolved'. This should go on the incoming side of the Jira connection."
Here is what Aida might generate:
def statusMapping = [ "To Do" : "Open", "In Progress" : "In Progress", "Done" : "Resolved"]def remoteStatusName = replica.status.nameissue.setStatus(statusMapping[remoteStatusName] ?: remoteStatusName)
Click Discard if the output is off. If it looks good, click Insert Changes, then Publish to save and roll out the changes.
Use Case 3: Route ServiceDesk Plus Tickets to Specific Jira Projects Based on Site or Category
For MSPs and large IT teams, different customer sites or product categories need to land in different Jira projects so the right dev team picks them up.
Set up conditional logic on the ServiceDesk Plus outgoing side that reads the Site or Category field and picks the destination Jira project accordingly.
A sample prompt to Aida:
"When the ServiceDesk Plus ticket Site field equals 'North America', send the work item to the JIRA-NA project. When it equals 'Europe', send it to JIRA-EU. For all other sites, use JIRA-GLOBAL."
The generated script will look something like this on the outgoing side:
def siteToProject = [ "North America" : "JIRA-NA", "Europe" : "JIRA-EU"]def siteName = issue.fields."Site"?.valuereplica.project = nodeHelper.getProject(siteToProject[siteName] ?: "JIRA-GLOBAL")Regional dev teams now only see work items relevant to their scope, and updates still flow back to the original ticket no matter which project handled it.
Use Case 4: Sync Comments While Keeping Internal Notes Private
A common ask from customers is filtering comments so that public conversations sync, but internal notes (the kind agents leave for each other) stay inside ServiceDesk Plus.
On the ServiceDesk Plus outgoing side, filter out internal comments before they leave. On the Jira incoming side, accept all incoming comments since they will already be public by the time they land.
Sample prompt for the outgoing side:
"Only send public comments from ServiceDesk Plus to Jira. Skip any comments marked as internal notes."
The script Aida produces might look like this:
replica.comments = issue.comments.findAll { !it.internal }
Now developers see customer-facing context without getting flooded by agent-only chatter, and sensitive internal discussion never crosses the boundary.
Use Case 5: Sync Multiple Jira Work Items to a Single ServiceDesk Plus Incident (Parent-Child Linking)
A single ServiceDesk Plus incident often spawns multiple Jira work items: one for a code fix, one for a config change, one for documentation. You want all of them linked back to the parent incident so support can track remediation as a whole.
To pull this off, store the ServiceDesk Plus incident ID in a custom field on each Jira work item, and use that field to maintain the parent reference.
Here is what the Jira incoming script generated by Aida could look like:
replica.customFields."SDP Incident ID" = issue.customFields."SDP Incident ID"On the ServiceDesk Plus outgoing side, fetch the parent incident based on the ID stored in the custom field:
def remoteIncidentId = replica.customFields."SDP Incident ID"?.value if(remoteIncidentId && firstSync){def localRequest = httpClient.get("/api/v3/requests/"+remoteIncidentId) if(localRequest == null) throw new com.exalate.api.exception.IssueTrackerException("Request with ID "+remoteIncidentId+" was not found") issue.id = localRequest?.idissue.key = localRequest?.keyreturn;}
If the request is found, the link is established. If not, the exception fires so you know something is off.
Use Case 6: Build an MSP Hub-and-Spoke Architecture
If you are an MSP running Jira internally and connecting to multiple customer instances (some on ServiceDesk Plus, some on ServiceNow, some on Zendesk), Exalate lets you treat your Jira as a central hub with each customer connection running independently.
The setup looks like this: a single Jira instance acts as the hub, with separate Exalate connections going out to each customer's ServiceDesk Plus instance. Each connection has its own sync rules, field mappings, and trigger conditions, so Customer A's data sync logic never touches Customer B's.
Sample prompt for one customer connection:
"On the Jira outgoing side, only sync work items with the label 'customer-a'. Map the work item to a ServiceDesk Plus request in their queue, and include only the summary, description, priority, and attachments. Don't sync any internal comments."
This architecture means you scale by adding new connections instead of rebuilding integrations from scratch every time you onboard a customer. It also keeps each customer's data isolated, which matters a lot for compliance and trust.
If you have a specific use case to discuss, book a demo with our engineers.
Note: The code snippets above might need slight adjustments based on your environment. If something does not work as expected, reach out to us for clarification.
Supported Jira and ServiceDesk Plus Entities
Check out the comprehensive list of supported Jira Cloud and On-premise entities.
Here is a sample mapping between ServiceDesk Plus requests and Jira work items:
ServiceDesk Plus request <> Jira work item
-
subject ↔ summary -
description ↔ description -
priority ↔ priority -
status ↔ status -
requester ↔ reporter -
technician ↔ assignee -
notes/comments ↔ comments -
attachments ↔ attachments -
custom fields ↔ custom fields -
any field available via REST APIs
Other Resources
-
Start a free trial with Exalate, or book a call with our integration engineers to talk through your use case.
-
Using Exalate Classic? You can find its documentation here. Learn more about the difference between Exalate Classic and New Exalate.
-
Head over to our Trust Center for security details.
-
Got configuration questions? Get answers on the Exalate Community.
-
Join our Webinar series: The Sync Room, where we unpack integration painpoints, the latest AI trends in the integration space, and a lot more.










