Overview

ManageEngine ServiceDesk Plus (SDP) On-Premise ships with a native Automation engine — Custom Triggers, Business Rules, Custom Functions, and outbound Webhooks — that is powerful enough to build real two-way integrations with third-party tools like JIRA, without relying on middleware such as Zoho Flow. Because both platforms expose REST APIs and support outbound webhooks/automations of their own, SDP and JIRA can talk to each other directly: SDP can call JIRA's REST API, and JIRA's own Automation for Space (Jira Automation) can call SDP's REST API back.

This article walks through two real, end-to-end use cases that were built and tested purely with native capabilities on both sides. They are intended to demonstrate the flexibility of SDP's automation stack to customers who are evaluating ServiceDesk Plus alongside — or in place of — heavier integration platforms.

What You Will Build

● Use Case 1 — JIRA Sprint Auto-Completion from SDP: a JIRA Sprint automatically raises a Change in SDP for CAB approval, and once that Change is approved and completed in SDP, the JIRA Sprint is automatically closed.
● Use Case 2 — Auto-creation of a JIRA Issue from a High-Priority SDP Ticket: a High Priority SDP request automatically creates a linked JIRA issue, and once that issue is resolved in JIRA, the originating SDP request is automatically closed.

Prerequisites

● SDP On-Premise with Automation (Custom Triggers), Webhooks, and Custom Functions (Deluge) enabled for the relevant modules (Change and Request).
● A JIRA Cloud with Automation access, and a JIRA API token with permission to create and transition issues.
● Network reachability between the two systems (SDP must be able to reach JIRA's REST endpoints, and JIRA's automation engine must be able to reach SDP's REST endpoints, e.g. via a reverse-proxy/tunnel such as devtunnels if SDP is hosted on-premise behind NAT).
● User-defined fields (UDFs) created in advance on both sides to carry cross-system identifiers (JIRA Sprint ID/name/dates on the SDP Change; the SDP Request ID and JIRA Issue Key as custom fields on JIRA).

Use Case 1 — JIRA Sprint Auto-Completion from SDP

In this use case, one issue inside a JIRA Sprint is deliberately reserved to represent "Sprint Sign-off." It sits alongside the sprint's normal delivery issues, but its only job is to trigger a Change Request in SDP once the team is ready for the sprint to be reviewed. When that sign-off issue is moved to Done (or a custom completion status), JIRA Automation fires a webhook into SDP that raises a Change, pre-populated with the Sprint's ID, name, start date, and end date. A Change Advisory Board (CAB) reviews and progresses that Change through SDP's standard workflow. The moment the Change reaches a defined "completed" status, SDP automation fires a webhook straight back into JIRA's Agile REST API, closing the Sprint automatically.

End-to-End Flow

Step 1 — JIRA Automation: Raise an SDP Change When the Sprint Is Ready

Configure a JIRA Automation rule (Space settings → Automation) that listens for a work item transition into an "In Progress / Done" state. Scope it with two conditions so it only fires for the designated sign-off issue: Issue Type equals Story, and Sprint is not empty. The rule's action is a Send web request (POST) to SDP's REST API endpoint /api/v3/changes.

The request body maps live smart values from the JIRA issue's sprint into SDP's Change UDFs — the sprint's numeric ID, its name, and its formatted start/end dates — and pins the Change to a specific Change Template (here, "Jira CAB Approval Test"), so every sprint sign-off Change lands in SDP already following the correct CAB approval path.

Figure 1 — JIRA Automation rule "CAB change test": on transition to Done, POSTs a new Change to SDP with Sprint ID, name, start date and end date mapped into udf_sline_921–924.

Step 2 — SDP Custom Trigger: Detect CAB Completion

On the SDP side, create a Change Custom Trigger (Admin → Automation → Custom Triggers → Change) named, for example, "CAB Completed – From JIRA." Set it to execute When a change is edited, and match on two criteria: Change Template is "Jira CAB Approval Test" and Change Status is Implementation >> Completed. This ensures the trigger only reacts to Changes that originated from JIRA and have actually completed the CAB-approved implementation stage — not any arbitrary Change closure.

For the Perform Action, choose Action Type = Webhook and select the webhook created in Step 3 below ("JIRA CAB").

Figure 2 — SDP Custom Trigger "CAB Completed – From JIRA": fires on Change edit when Template = Jira CAB Approval Test and Status = Implementation >> Completed, invoking the JIRA CAB webhook.

Step 3 — SDP Webhook: Close the JIRA Sprint

Configure the outbound Webhook (Admin → Automation → Webhooks → Change) named "JIRA CAB." It issues a PUT request to JIRA's Agile REST API at /rest/agile/1.0/sprint/${{change.udf_fields.udf_sline_921}} — the Sprint ID that was captured back in Step 1 — using Basic Authentication against a JIRA integration service account. The Request Payload sends { "state": "closed", "startDate": ..., "endDate": ..., "name": ... }, which instructs JIRA's Agile API to close the Sprint. The result: the moment CAB sign-off is recorded as complete in SDP, the corresponding Sprint is closed in JIRA with no manual step on either side.

Figure 3 — SDP Webhook "JIRA CAB": PUT to JIRA's Sprint API using Basic Authentication, closing the sprint with state, startDate, endDate and name pulled from the Change's UDFs.

Use Case 2 — Auto-Creation of a JIRA Issue from a High-Priority SDP Ticket

This use case covers the opposite direction: work that starts in SDP and needs engineering follow-up in JIRA. The moment a new High Priority request is logged in SDP against a specific template, SDP automatically opens a corresponding Bug in JIRA — tagging it with the originating SDP Request ID — and writes the new JIRA issue key back onto the SDP ticket. From that point, the ticket is worked entirely inside JIRA. When the engineering team marks the JIRA issue Done, JIRA automation calls back into SDP and closes the original request, keeping both systems reconciled without anyone touching SDP again.

End-to-End Flow

Step 1 — SDP Custom Trigger: Detect the High-Priority Ticket

Create a Request Custom Trigger (Admin → Automation → Custom Triggers → Request), named "Jira HP," set to Execute on actions: Created, with condition Priority is High AND Template is "HP JIRA Ticket." The action is a Custom Function that runs a Deluge script named jira_hp — shown in full in Step 2 below.

Figure 4 — SDP Custom Trigger "Jira HP": on request creation, when Priority = High and Template = HP JIRA Ticket, runs the jira_hp Custom Function.

Step 2 — Custom Function Script: Create the JIRA Issue and Write Back the Key

The Deluge Custom Function reads the newly created request's ID, subject and description, then builds and POSTs a JIRA issue-creation payload to /rest/api/3/issue. The issue is created in the target JIRA project as a Bug with Priority High, and the SDP Request ID is stamped into a dedicated JIRA custom field so the two records stay traceable to one another from the JIRA side as well.

Once JIRA responds with the new issue's key (e.g. TEST-123) and internal ID, the script immediately calls back into SDP's own REST API with a PUT to /api/v3/requests/{id}, writing that JIRA key into a UDF on the originating SDP request (udf_sline_925). From this point forward, anyone viewing the SDP ticket can see exactly which JIRA issue is tracking it.

Step 3 — JIRA Automation: Close the SDP Ticket on Resolution

On the JIRA side, an Automation rule named "JIRA HP Update" listens for a work item transition To: Done, scoped with conditions Issue Type equals Bug and Priority equals High. Its action is a Send web request (PUT) to SDP's REST API at /api/v3/requests/{{issue.customfield_XXXX}} — the SDP Request ID field that was stamped onto the issue back in Step 2 — with a Custom data body of { "request": { "status": { "name": "closed" } } }.

An authtoken header carries the SDP API credential, and "Delay execution of subsequent flow actions until we've received a response" is enabled so the rule waits for SDP's confirmation before completing. The net effect: the moment engineering marks the Bug Done in JIRA, the originating SDP request is closed automatically — no follow-up needed from the requester or the service desk agent.

Figure 5 — JIRA Automation "JIRA HP Update": on transition to Done for a High-priority Bug, PUTs a status-closed update back to the originating SDP request via its stored Request ID.

Conclusion

These two use cases demonstrate that ManageEngine ServiceDesk Plus On-Premise does not need a separate integration platform to achieve meaningful, production-grade, bidirectional automation with JIRA. With native Custom Triggers, Webhooks, and Deluge scripting on the SDP side, paired with JIRA's own Space Automation, teams can build governed, self-healing workflows that keep change management, incident response, and engineering delivery in lockstep — a strong illustration of the flexibility SDP offers to organizations standardizing their service management and DevOps toolchains.

This article is provided for demonstration purposes. Replace all sample domains, credentials, field IDs and template names with values specific to your ServiceDesk Plus and JIRA environments before implementing in production.