You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I am attempting to integrate Jira Service Management with OpsGenie. I've created system level webhooks in Jira to interact with OpsGenie when an issue is created in a specific project. The webhook works for items when they are created, but not when they are updated. Since we have automation that provides valuable information to a ticket following its creation, this results in those fields being empty in the alert.
I have set these system level webhooks to trigger on both create and update. I've also set them on create alone as well as update alone. In all cases, only the create delivers (or at least registers) something to OpsGenie.
I also attempted to use automation to engage with OpsGenie, leveraging the OpsGenie webhook API key in the Send Web Request action, but these have yet to register in OpsGenie. This latter approach leads me to believe that the system level webhooks are triggering on updates, but not being recognized by OpsGenie. However, I have no evidence of this.
Ultimately, I need to be able to pass information from issues when certain fields have been populated, such as the responsible portfolio.
You'll have to give more information on how specifically you're using create and update. Are these separate triggers and thus separate rules? Are you using the multiple issue events rule? Issue events have been getting weirder and less reliable in JSM as JSM pushes more to happen after the old-school OSWorkflow events, and I've been using event listeners less and less.
In recent experience, Automation has been working most reliably with "When field changes.." automations. Consider using "When field changes for Status" as a trigger instead, or "When Responsible Portfolio changes". Yes, you'll have more rules to maintain, but each rule will be simpler, shorter and more reliable.
Unless I'm mistaken, your question about triggers appears to concern webhooks leveraging Jira automation. If so, yes, I have used the multiple issue events trigger. However, this is not how I started. Instead, I started with system level webhooks available in the System menu. In the case of system webhooks, the trigger options include Issue Related Events, from which I've alternatively chosen "Issues - Created," "Issues - Updated," and both together.
I've used multiple system webhooks for the same project and actions, identifying the project using JQL. I expected that applying the JQL would allow me to further refine which issues are sent to specific teams in OpsGenie (i.e. one webhook per team). However, to this point, only the "issue - created" property appears to have generated an alert to OpsGenie. I wouldn't expect an update to necessarily create an alert, though I would expect it to update an existing alert, or at least register somehow in OpsGenie. I see no evidence of this happening.
Since posting this, I've begun capturing the JSON payloads (i.e. in a separate webhook) to compare them to what OpsGenie includes in an alert. This has proven that updates are triggering webhooks in Jira but are not appearing in OpsGenie. It also shows that, even when the appropriate fields are populated in the newly created issues, the value for the field is not being translated in OpsGenie. I've attempted several permutations of the syntax to capture field values with no success to this point. The entire effort has been frustrating.
That's interesting to learn, thank you for the note. I haven't worked enough with OpsGenie to give you valuable insight in resolving this issue. You will have to collect your evidence, simplify it to the bare minimum showing the bug only, and request assistance from Support. Good luck. In the interim you may have to fall back on Jira notifications and automation rules which is nowhere near as tidy, easy to manage or professional.