How do you manage alert ownership in JSM Operations? Dynamic responders.

[Bartłomiej Jędrzejko]

Hi everyone,

I'm looking into how to handle alert ownership in Jira Service Management Operations and trying to figure out the best pattern.

The intended configuration is the following: we want to use the native Services schema available in Assets, where each service object has a responders attribute (user or team). Alerts are coming from a monitoring system and already include information about which service is affected, so it's clear which team or owner should be assigned. When an alert comes in JSM should check which service is affected, look it up in Assets, retrieve the responders and automatically populate this information into the responders field. This assignment should happen at the alert level, not the incident level, so the right person is notified early and can then acknowledge the alert and decide whether to escalate it to an incident.

The problem is that JSM doesn't seem to support this kind of dynamic assignment in alerts. It looks like you have to define a fixed user or team in the integration.

Has anyone run into a similar issue? Curious whether you found a way to make this work or just handled alert ownership differently in your setup. Any ideas are welcome! Thanks!

[Marc -Devoteam-]

Hi @Bartłomiej Jędrzejko 

Other option, besides the one from @Andrea Robbins 

Is to use automation and API calls in the rule.

In theory, when an alert is created. based on the service, use a web request to get the team id of the team listed on the service in assets.

Store this information into a variable, then do a second web request to update the created alert, use API endpoint api-v1-alerts-id-responders-post to add the team to the alert.

I have not don it this way, but in the past, before you could assign multiple teams to an alert, it did this by using a lookup table in the automation rule, to match the team name and based on this to get the Team Id from the lookup table and then edit the alert via an API call

[Andrea Robbins]

The issue (unless they've fixed it) is Atlassian hasn't exposed the Affected Service field on the alert in the REST API or in the smart values in alert automation rules. It's a lot of work to set up, but similar to what Marc is saying is that you can have like an extra property be set to like the key of the affected service, and then do an object lookup. We have done that before, but you cannot set the affected service field either, this would be more just to set the alert responder.

I know they've been working on getting Affected Services more integration (like adding it as a field to set on the incidents for syncs), so maybe it has been fixed. Trying to be optimistic :D 

[Andrea Robbins]

You are correct! You can set up integration rules to create alerts with Affected Services, but you cannot set the alert responder to be the affected service's responder team (trust me I've tried!).

What I've done is have an alert responder be some sort of triage team like a Network Operations Center Team, or have it be auto set based on the integration.

I haven't tested this yet, but recently, you can create a Jira Sync to copy the alert affected service to the incident affected services field (like when it generates an incident), and the responder field will be added as an incident responder.

Let us know if this ends up working, thanks!

[Bartłomiej Jędrzejko]

Hey Andrea,
I actually tested the Jira Sync approach and it does work well at the incident level. Responders get populated correctly from the affected service. The problem is that it creates an incident for every alert, and I really want to avoid that. Some alerts turn out to be false positives, so I don't want to generate incidents for all of them unnecessarily.

The triage team approach is also something I considered, but with multiple different service owners in the mix, routing everything through a central team introduces a delay and that's exactly what I'm trying to eliminate. The whole idea is to get the right owner notified as early as possible, at the alert stage, so they can assess and decide whether it's worth escalating to an incident at all.

So the gap really remains at the alert level. The automation actions there are just too limited to do a dynamic Assets lookup and push the result into the alert responder field. It feels like a missing piece in JSM Ops that is available in other tools for example PagerDuty.

Thanks again for sharing your ideas ;)

[Andrea Robbins]

If you don't want it to generate an incident, you can turn it off by unchecking that option. You can use a sync to generate alerts only if desired. I honestly am not a huge fan of the OOTB JSM Ops functionality, so I customize everything, but the syncs can work for some use cases!

What I have done is create a manual triggered automation rule to generate the incident that brings over:

- The alert message -> incident summary

- The alert description -> incident description

- I use an extra property that was already set that has the host name of the affected server -> incident asset field for affected infrastructure (custom)

- via CMDB linkages, I find any affected infrastructure or products that are linked to the affected server(s) above and set the proper field on the incident for that

- I use another extra property that was set with the name of the team who should respond -> I set the responder team on the incident to this team