Hello,
I need to sync jira service management cloud (a particular project) with an external, unusual, ticketing system.
I thought that I can via webhooks send the tickets to the 3rd party system… but it seems like I can only send some attributes like ID.
So my question is, is my understanding right?
The need: when ticket is escalated in Jira WKF → send it to 3rd party system, it gets treated, once done, send it back to Jira.
I imagine this sequence, please confirm if it’s the right understanding, do not hesitate to suggest improvements:
1- add webhook to jira transition in WKF
2- once a ticket is escalated–> fire webhook
3- webhook will send the ticket ID to 3rd party system
4- 3rd party system will perform a GET via rest API to get the ticket and create it
5-once done, perform a POST via rest API to Jira to update ticket
Welcome to the Atlassian developer community @Dhia,
is my understanding right?
No, unless there’s a constraint that the other system can only read info from URLs not JSON request bodies. Jira’s webhook payloads contain a lot of information. Basically, you get everything available from Get issue (without expands) and some additional context. Hopefully, you don’t need step 4.
Overall, webhook is a pretty simple solution on the Jira side, but it sounds like the trade off is to push the complexity to your unusual ticketing system. Another possibility is to build a more explicit integration using Forge and a workflow post function. One advantage is the integration would be more visible in the Jira workflow. Another is that integration would have more targeted context: the signal to the other ticketing system would only happen on the specific transition. As a result of both, I think this creates better error handling, where Jira can be more “aware” of problems, if communications with the other ticketing system is lost. Both also contribute to a more durable integration that doesn’t break when an admin needs to change workflow. In short, the “post function” pulls the complexity closer to Jira. The trade-off is the additional complexity in building a Forge app compared to the much simpler webhook.
If you do build a Forge app, then you still need step 5. But the Forge way would be a web trigger (it’s like the opposite of a web hook). Be aware that you have to “roll your own auth” on web triggers to secure them.
Set up Webhook in Jira: First, you need to create a webhook in Jira to trigger an event when the ticket is escalated in Jira’s workflow.
Trigger Webhook on Escalation: When a ticket is escalated in Jira, the webhook you set up will be triggered.
Webhook Payload: The webhook will send a payload containing information about the escalated ticket. The payload might include attributes like the ticket ID, summary, description, assignee, etc. Make sure the necessary information is included in the payload.
Send Data to 3rd Party System: Your 3rd party ticketing system should have an API endpoint ready to receive data from Jira. It should be able to understand the payload sent by Jira’s webhook and extract relevant information like the ticket ID.
Create Ticket in 3rd Party System: The 3rd party system, after receiving the payload, should use the extracted ticket information to create a corresponding ticket in its own system. This can be done via a REST API call (e.g., using POST).
Handle Ticket in 3rd Party System: The ticket in the 3rd party system will be processed, treated, or worked on as required.
Update Ticket in Jira (Optional): If you want to sync changes made in the 3rd party system back to Jira, you can perform a POST via Jira’s REST API to update the original ticket in Jira. This step is optional, depending on your requirements.
Other option:
Use a decentralized Integration solution, for cxample Exalate who will do this. I have been using it for quite a while and it works awesome and super fast!