The New Jira Incident Workflow - how will that improve how we work today?

At Atlassian Teams '24 we got a lot of information on major changes coming to the Atlassian products soon. One of the biggest changes are how Incident Management will work in the Atlassian products.

So how will these changes improve how we work today, and what can we expect to see soon in Jira and Jira Service Management?

Opsgenie and the new Operations feature

Opsgenie has been a weird product for a long time. It has great features, but the connection between alert and incident, especially incidents in Opsgenie and Jira, has never really felt intuitive. Opsgenie has also always felt disconnected and underutilized as people rather setup email imports for alerts instead, spamming the living...well you know, out of the projects instead of using a proper alert setup.

As we now get a new Operations feature where Atlassian is moving the Opsgenie functionality, things are looking to improve a lot. Not only is this reducing the gap between where we manage alerts, but it also connects it to incidents in Jira in a much better way!

As an added bonus, it also gives more use to the Team feature by connecting it to the Operations feature and quite nicely replace the Teams in Opsgenie.

Managing alerts becomes a team activity, not a specialized feature.

By adding the Alerts to the Team function, Atlassian is effectively breaking down the barrier for managing alerts that existed before. You no longer need to jump to another tool that have a different design and you no longer need to pay for another tool, just to set up alerts and monitoring for your tools and services.

Teams can now manage all of this on their own, and that add another dimension to why it makes sense to create a Team in the Atlassian products.

It is super easy to work with, and you can quickly set up multiple integrations and alerts for different things without almost no instructions.

This adds more autonomy to the teams, and it reduces the clutter from adding alerts into Jira as new tickets/issues or as comments.

More intuitive way to generate incidents

In Opsgenie there was no intuitive way to generate incidents from alerts. You could automate it, of course, but it seems most people did not understand the point of having an Opsgenie incident instead of a Jira incident. There was not really a connection between the incident you had in Jira and the incident you had in Opsgenie, which confused people.

With the new Operations feature, this is removed, and you can create incidents directly from the alert into one or many Jira projects. These incidents are then connected to the alert, or even multiple alerts if you want.

This is a lot more intuitive, and it makes more sense based on how we work in Jira and Jira Service Management.

Working with incidents now make the incident the focal point

When you worked in Opsgenie, there was very little connection with the incident in Jira. Yes, you could set up automation to push comments to Opsgenie or notes to Jira, but there was a clear disconnect between where you worked and where you communicated.

In the Operations feature, this is no longer the case. The incident you are working with is now the only place where you need to be, as all the functionality is now at your fingertips there. You have your linked alerts, you have your communication options of Slack, Teams or the ICC. You have the affected services, stakeholders and if you add the integration with Statuspage, then you can even manage the communication from the incident itself!

Furthermore, you have information on the severity, Impact, SLAs, recent deployments for the affected services and when the incident is closed you have the PIR (Post Incident Review) built right in.

In short, Atlassian have taken what was awkward and confusing and made it great.

The last puzzle piece - the Incident Tab for development teams

While not much is yet revealed about the Incident Tab that will be available in Jira projects, we do know that it will be connected to Services from Jira Service Management.

The concept is that as a developer, you should see all incidents related to your assigned Services, even if they are not created in your Jira project. This will allow users to create incidents in one, or many, Jira Service Management projects and as long as they are connected to the Services your project is connected to, you will see and be able to interact with the tickets in your development Jira project as if it was created there.

The one thing that is still unclear for me regarding this functionality if how it works with access rights. I assume you will still need some form of role in the Jira Service Management projects to prevent users from accessing tickets they should not have access to.

This role should not consume a Service Desk Agent license, so I assume we will see another type of role. Or it can somehow be connected to the Service so you can automatically get this role if you own a Service, but then there has to be some security in place so you can not simply remove the existing team and add another one.

Or maybe they will just use the Collaborator role, which they are already using for Developer Escalations?

The Incidents tab is amazing, but what about Developer Escalations?

If you have used the Developer Escalations, then you probably recognize that the Incidents tab is similar to that functionality. The difference is that the Incident Tab lives in the Jira Development projects, while the Developer Escalations live in the Jira Service Management projects.

It would make sense if the Developer Escalations also were located in the Jira Developer projects, as that would remove the awkward jumping to other projects to help support for these escalations.

Incidents in Jira Service Management now becomes the Root incident

With these changes, you will now also have a Jira Service Management incident that will act as the Root incident that can show up in multiple teams incident tabs. From there they can create their own incidents and connect them to that root incident, which will allow every team to work in the incidents related to their code, while still keeping everyone updated on the progress in the root incident.

This is brilliant!

While there is no standard functionality to create development incidents yet, I think most admins will add a manual triggered automation for it as that makes sense for this use case.

As the PIR are also tickets, you can add multiple ones in the same root incident. You can also use Forms and just have one PIR with multiple forms.

Conclusion and what I think is still missing

To me this is by far the biggest, and best, change to incident management I have seen from Atlassian and I think it is amazing. This streamlines the whole process from start to finish, and it removes several awkward and confusing parts whereas an admin you either had to hack Jira, or spend countless hours trying to explain why things where they confuse the users.

I absolutely love this.

There are however some friction points still there that should be addressed and have solved in the future. These are mostly related to product misalignment, it seems.

Compass is not yet aligned?

For some, very strange reason, we have two teams in Jira right now. One that is the official Team that you create from the Team tab in the navigation. On top of that, we also have a Team feature in Compass.

This becomes confusing, and I think these functionalities should merge into one team function in the future.

There are also different roles for Operations and for Team, and you manage them in different places. This makes it unnecessarily complicated to manage who has access to what and in what way. I would prefer to have the Teams page updated and brought more inline with the overall design when it comes to managing the Team.

The current page is more like a portal for public use and I think it makes sense to separate the internal functions such as manage user and access along with the Operations and Compass functions and then one External function like showing what the team do and who is on the team.

If we want to take this a step further in the future, we could possibly even add a Jira Service Management connection to allow others to contact the team if they have a Jira Service Management project setup...

We have a similar situation where Services are not synced with Compass, but you have to sync them manually by importing them to Compass.

Alerts don't have access to custom fields

This is a big oversight, or it just has not made it into the product yet. With alerts now existing in Jira it should also have connection to custom fields (and also eventually forms, but that is less important right now). Adding this will allow us to enrich the alerts from different systems with more information that we can filter and work with.

Adding this will also allow us to connect alerts in more ways, like attaching to Assets so we know for example what customers are affected by a potential incident so we can assess the alert better based on business information.

Alerts have no connection to Services?!

I think this is one of the most requested features for Opsgenie and for some reason it is still not added here. Even if we don't have custom fields, I think Services should be an option even for this first iteration.

Statuspage can be improved

With the integration of Statuspage into Jira Service Management, we get a very nice way to manage our communication on the Statuspage itself from the Incidents.

In Operations, however, it is not present other as an integration that basically sync the statuses between an Alert and Statuspage. What I would like to see here is a connection, so I can see if we already have something on the Statuspage. This could be connected to Services or something similar to show information on what is currently added on the connected Statuspage, or Statuspages.

There is room for improvement, but this fall incident management will be much easier to work with!

While there are always things that can improve, this is by far the biggest and best change for incident management from Atlassian...ever.

I am super excited for these changes, how about you?