We are facing issue while integrating zabbix with jira service management

[Nivitha Titus]

alerts are created and closed when they are created and closed in zabbix . but when there is an update action like acknowledge or update priority it is not reflected in the jira service management .
i am susing the send2go binary from the package and actioncommands mentioned in this page .https://support.atlassian.com/jira-service-management-cloud/docs/integrate-with-zabbix/

[Nivitha Titus]

@Gabriela - LeanZero thankyou for hte answer . since we are using zabbix 7.2 we followed the section for zabbix 6.4 and above . And also added sen2jsm script for the update and recovery operations. even then the acknowledge the alert from zabbix doesnt work . i tried to change the priority after acknowledgement . what i understood is none of update operations work . My question is already build binary for send2jsm which is included in the already built rpm zabbix package from atlassian or do we need to include custom scripts for that ?

[Gabriela - LeanZero]

Hi @Nivitha Titus, create and close working while updates don't points at an empty Update Operations table. In a Zabbix trigger action the three tables fire on different events. Operations on the problem, Recovery Operations on the resolve, and the third one on an acknowledgement or a severity change. Yours is wired for the first two.

The same action fixes it. Alerts, Actions, Trigger Actions, open yours, Operations tab, then add your send2jsm script to that third table with Current Host as the target, the same way you set the other two up.

Check which section of that page you followed, too. Only the 6.4 and above one tells you to repeat the step for Update Operations, the 3.2 to 6.2 section stops at Recovery Operations.

That page also describes send2jsm as creating, acknowledging and closing alerts and doesn't mention severity, so confirm the acknowledge lands before you count on the priority.

[Nivitha Titus]

@Gabriela - LeanZero thankyou for the answer . since we are using zabbix 7.2 we followed the section for zabbix 6.4 and above . And also added sen2jsm script for the update and recovery operations. even then the acknowledge the alert from zabbix doesnt work . i tried to change the priority after acknowledgement . what i understood is none of update operations work . My question is already build binary for send2jsm which is included in the already built rpm zabbix package from atlassian take care of this ackwlede actions  becasue i dont see any flags for acknowlefe in the send2jsm.go file . Do we need to include custom scripts for that or edit the send2jsm script to change the behaviour

?

[Gabriela - LeanZero]

There are no acknowledge flags in send2jsm.go because there don't need to be. It's prebuilt, and you don't have to edit it or write custom scripts.

And it isn't your setup. JSDCLOUD-16196, "When Zabbix alert is acknowledged, the JSM alert is not acknowledged", reproduces on Zabbix 7.2.0 and above, with no known workaround. You're plainly still hitting it, so add your version to the ticket.

The stock command can't express it anyway. All three tables send the same -triggerStatus='{TRIGGER.STATUS}', only ever PROBLEM or OK, so nothing in the payload says an update happened. JSM evaluates Create alert ahead of Acknowledge, so an acknowledge re-matches Create. That third table was needed, it wasn't enough by itself.

There is a way through. That same page allows extra custom arguments after the flags. Append ackStatus '{EVENT.ACK.STATUS}' and it arrives as {{_payload.ackStatus}} in the filter dropdown. Add ackStatus equals No to the Create rule with match-all, then ackStatus equals Yes on Acknowledge. triggerStatus is untouched, so your creates and closes carry on. Untested by me, so try it on one trigger first.

Priority is separate. None of the incoming actions change a live alert's priority, it's only settable on create.

[Nivitha Titus]

@Gabriela - LeanZero I  applied the workaround and I also found another issue . I am testing creatign test alerts from same item multiple times . The alias is set as {{ triggerid_hostname }}. 
So when i close and create a new alert we have the same alias for the closed one and opened one but at a point there is only one open alert . But when an ack is triggered from zabbix the acknowledge action is not triggered saying the alert with the alias doesnt exist eventhough there is an open alert . if this is a new alert with no previous closed alert it works . Is this also expected ?

another question regarding the bidirectional sync . With our subscription we can have bidirectional sync with zabbix and jec . 
when i create an integration for bidirectional sync , is it enough to create integration for zabbix plugin or shoudl I also have another integration created in ui for jec ?

[Gabriela - LeanZero]

Correction first. JSDCLOUD-16196 is Closed, resolution Fixed, July 2025, so ignore what I said about adding your version to it. The "no known workaround" line there is from the original description.

On the alias, no, that isn't expected. Acknowledge is documented to look for an open alert whose alias matches, and only one open alert per alias can exist, so yours should resolve. Failing only when a closed alert shares the alias is the part that shouldn't happen.

You already send a per-occurrence id. The command from actionCommand.txt carries -eventId='{EVENT.ID}', so it reaches the rule as {{_payload.eventId}}. Point the alias at that, and change it on Create alert, Close alert and Acknowledge alert together, since each holds its own alias and your closes break if they disagree. The trade is dedup, on a trigger set to multiple problem event generation you get an alert per event instead of one with a count. I haven't run this on Zabbix myself, so try one trigger first.

Bidirectional is one integration here. The setup page has you copy the Zabbix integration's own API key into jec-config.json, and that's the integration JEC serves. The generic JEC page telling you to copy the key from "the JEC Integration page" is what sends people off building a second. JEC also only carries JSM back to Zabbix, so it isn't in the path of the ack you're chasing.