Status of linking alerts to JSM incident tickets (broken feature)

[Ken Young]

I am interested in learning if others are having issue linking Alerts to JSM incident tickets.  Without the ability to have this automatically linked, you have to result to APi workarounds.  With the new restrictions on API usage, I think that this needs to be fixed.

Are there tickets other than https://jira.atlassian.com/browse/JSDCLOUD-14539 that help to track the status of this issue.  If you are interested, please upvote this.  

I realize this isn't a support channel, but important to know what others are experiencing, as well as to bring attention.

[John Funk]

Hi Ken,

I recently created a manual automation rule that will be executed from an Alert that creates an Incident in a JSM space and links the two automatically. It also includes input prompts in the manual rule so that I can select which Work Type it gets created for. 

[John Funk]

Hey Ken - please respond in line to the thread so users can follow the conversation. 

Yes, that is why I created the automation rule, because the sync wasn't doing what I wanted it to do. You can set the rule up for creating the incident when the alert gets created - just change out the trigger and add any needed conditions. We just had a different need for the process. 

[John Funk]

@Ken Young  - any update?

[Ken Young]

Native Sync Functionality is still broken.  I went with a restful work round recently --- waiting for verification.

[John Funk]

So using the automation rule above didn't work? 

[Ken Young]

Different use case, we create work items via Sync, not using automation. Our automations run only to "clean up" what sync cannot handle.  I add the id via a existing unused field (i.e. Affected Hardware) that I can read from the cleanup automation, and use the rest api to apply the link.  

The purpose of this thread orginaly was to ask if anyone else was trying to do this via sync.  There were many more features that have been in the Atlassian automation pipeline (or so I thought from previous webinars) related to the direct management of alerts via automation, but it appears that most of those items haven't made it to production yet.

[John Funk]

Gotcha - I missed the sync part because we don't do it automatically - it's on a case by case basis as to whether the Alert gets turned into an Incident. Thanks for the clarification!

[John Funk]

But also curious as to what advantages is it for you to do it by sync versus by automation rule. 

[Mark Hankins]

We're having the same issue.  We saw it a while back and it was broken again for a while, then we raised a support ticket and it magically got fixed.

It's now broken again, but only in some cases.  Logs say it worked fine.

Raising a support ticket again now. It's impacting lots of Production Atlassian customers. Second time in a month I've had to raise this same issue, last time, it was the result of Atlassian engineers "fixing" something else.  This shows there are significant holes in Atlassian's regression testing strategy.

https://support.atlassian.com/requests/CES-160954/

[Ken Young]

Thanks for the response.  The issue we have is that it "mostly" works as in the Sync create the alert, but doesn't link the alert to the ticket (but is shows correctly in the alert).  When you are trying to to automate an pull in more metadata from the alert into the issue, it just breaks from there.

Thx

Ken

[Mark Hankins]

I had to give up on syncs completely because they were so reliable, and didn't allow for the customization we needed.

Now when I need to create an Alert, I do it from a REST API call in the automation, which is also ridiculous because:

1. It means you have to store your API tokens/keys in the automation, which means managing them all separately if you ever change them.

2. A REST call from jira to jira service management (or sometimes jsm > jsm even) now has an external API call round trip to wait for a request/response.  It used to be a "jira" integration, but Atlassian in their wisdom decided to remove that integration for some reason (even though syncs don't work properly and don't have Feature parity).

3. Half the time when you use an automation to create an incident from an alert trigger, it says it's linked them (but actually hasn't) - which is terrible.  That's core functionality our on-call engineers rely on to auto-create incidents for them for high-priority alerts - now broken out of the box.

4. Responder alerts were the other option, but they're not finished implementation either, since half the time they don't work either, and when referencing teams for them, it's a crapshoot between having to reference some kind of "ari" field, or getting an OpsGenie Team object back instead.

I wish Atlassian had just done their OpsGenie to JSM migration and launched a whole new set of API's, because honestly, this current migration is not very fun to try to deal with.

If anyone at Atlassian reads this, PLEASE fix the core functionality before adding any more pointless features.  AI is useless before the basics work reliably.