Notify each organisation members about comment in a ticket

Question

Hello!

I have a JSM project where tickets are shared between customers inside same organisation. Now I need to find a way to notify each organisation member about e.g. comment in a ticket (yes, in that particular case spamming is an option).

What I found so far is that each organisation member can turn on notification in a single ticket but in this case is not a solution.

Does anyone facing this issue and how did you solve that?

Gabriela - LeanZero · Answer

Hi Sebastian,

Thanasis covered the missing setting, so I tried the participants route on a test site today with the members looked up live, which means you don't have to keep a fixed list. My rule ran on Work item commented with {{comment.internal}} equals false, did a Send web request GET to /rest/servicedeskapi/organization/{{issue.Organizations.id}}/user?limit=50 with a Basic auth header (an agent account's email and API token, base64'd, with Hidden ticked) and "wait for response" ticked, then an Edit work item action with this under More options, where customfield_XXXXX is your Request participants field and you'll need to look up its id on your site:

{"update":{"customfield_XXXXX":[{{#webResponse.body.values}}{"add":{"accountId":"{{accountId}}"}}{{^last}},{{/}}{{/}}]}}

Three of the four members of my test organization showed up as participants about ten seconds later (the fourth was an admin account on our site that didn't get added, and I didn't dig into why), and the doc says participants get "the same notifications as the reporter", so your usual Public comment added email should cover them from the next comment on, though the comment that runs the rule may only reach them as the "added you as a participant" mail. Running the same steps when the request is created would get them in earlier, but I haven't tried that. It has limits, though. With two organizations on one request the URL renders both ids, the web request fails and nobody gets added, so you'd need a branch per organization, which I haven't tested. The endpoint also pages at 50, the reporter gets added too, and API tokens expire within a year by default, so the rule stops working when that one does.

A lighter option is Send customized email to "All customers involved", which the doc says reaches "customers whose organization has been added to the work item"; the rule ran for me, but I couldn't check who actually received the mail, on either route.

Thanasis Nikolaou · Answer

Hi @Sebastian Krzewiński

Short version: there's no setting for this today. When a request is shared with an organization, every member only gets the first "Organization added" email. After that, each person has to open the request in the portal and turn notifications on, and Atlassian confirms there's no option to change that default: https://support.atlassian.com/jira/kb/how-to-manage-customer-organizations-in-jira-service-management-cloud/

The feature request is JSDCLOUD-4570 (currently "Reviewing"), so vote for and watch it: https://jira.atlassian.com/browse/JSDCLOUD-4570

If you need it now, add those people as request participants instead. Participants count as "Customers involved", so they get the Public comment added notification like the reporter does. For a small, fixed group you can set Request participants with an automation rule when the request is created.

Two small helpers: you can edit the Organization added notification to tell members to turn notifications on, and a customer can still switch a request off themselves.

Matthew Sinclair · Answer

The problem is the JSM ticket is intrinsically designed to only notify watchers/request participants/agents on the ticket.

Even if you where able to find a solution to the issue - you would be required to "share with" the ticket to the entire org(s) which effectively causes a nuclear blast every time a ticket is spun up. (In emailing everyone)

Only work around I could speculate attempting is seeing if there's a way to to use Jira Automation to ping an Organization - but that is a little risky considering the potential blast radius.

That and you cannot defeat the users personal settings outside brute forced email action in Jira Automation.