28. 08. 2024 Fabrizio Dovesi Atlassian, Service Management

Automate the Clustering of Similar Cases for Effective Handling of a Significant Volume of Incoming Alerts

This guide will show you how to enable your team to handle multiple cases simultaneously, letting you manage them as if they were just one.

In which scenarios would this solution offer users a valuable benefit?

Have you ever had to discard a significant number of cases, requests, or emails because there were simply too many to manage effectively? Have you ever observed instances where IT service queues became unwieldy “logs of cases” that weren’t managed promptly?

In such instances, it’s crucial to consider automated and well-engineered solutions that align with the underlying business processes.

The objective is to streamline the process of managing a large number of cases that may pertain to the same issue or have a common characteristic. This will enable your team to handle these cases as a single unit, allowing them to focus on important cases and react quickly when necessary.

This article provides an example of how to handle this properly in a real-world scenario. To illustrate the potential of this solution in a practical context, we can consider a Jira Service Management project where reports of potential alerts related to phishing or data security breaches are created via email. These emails can then be forwarded both from different external systems and by users via their mailboxes.

How can we achieve this solution in a structured way?

As always, I recommend beginning with a solution design that incorporates the relevant criteria. Engaging in paper-based reasoning and sketching out the solution can be crucial at this stage to identify potential improvements and facilitate the exchange of ideas among team members.

The solution that follows is illustrated with a practical example to facilitate a more comprehensive understanding of its components. We will examine the case of a team responsible for IT security, tasked with addressing hundreds of potential alerts daily. This solution can serve as a foundation for those seeking to consolidate a significant number of similar or related cases and is the result of real use case work for one of our customers.

Before we started to design the solution for them, the IT Security team was unable to effectively manage the high volume of incoming alerts in their Jira project, the majority of which were false alarms. As a result, the queue of cases wasn’t being either managed or checked regularly, which is an inefficient use of time for the team and colleagues who raised the cases.

The solution must meet the following requirements:

It must be able to handle the potential risk of receiving many issues simultaneously moments apart
It must be capable of handling a high number of similar issues, driving only one of them
It must be able to highlight among the hundreds of open issues which are the most recurring and/or urgent cases to handle
It must be sustainable in terms of performance and the resources required of the system
It must be safe and reliable

In summary, our solution addresses these requirements by grouping similar issues under an Epic based on a predefined logic, which I’ll explain in more detail below.

Several configurations of the Jira system have to be applied to make the solution work, but all of them are restricted to work only on a single project if needed. Below I’ll show you which aspects of the general and design configurations have been revised; however, the core of the solution is undoubtedly the automation part.

Create new custom fields (with dedicated and restricted context to one single project)
Update project Screens (edit existing ones + create a new transition screen)
Update project issue types (add Epics)
Update Service Request Workflow into the project
Create nr.3 project-based Automations

Automation

As the crucial component of the solution, I’ve configured some automation to help our team save time by avoiding manual and boring actions. The solution relies heavily on a set of 3 Jira automations working in harmony. Below, I’ll describe how each of these processes operates and its purpose.

It’s fundamental to keep them monitored to prevent undesired effects in some rare cases (such as, when issues with an unreadable “Summary” comes into the project queue), or other special events (like a downtime or upgrade to the system), etc…

Since we’re expecting to manage a huge number of issues on this project with possibly hundreds and hundreds of incoming cases per day, we must keep these nr.3 automations monitored in order to mitigate eventual risks as much as possible.

Before we proceed with the specifics, it’s important to first provide an overview of their functions and applications:

Automation 01: When a new case (Issue) is created, the system checks whether a reference container (Epic) for similar cases already exists. If there isn’t one, this automation creates and links it to the new case. If one does, it just add an internal comment to it
Automation 02: Scheduled to run every 10minutes, it searches for cases without a reference container (Epic) and links the retrieved reference to existing ones (by populating them with a Parent link).
Automation 03: Once the agent has closed the referenced container (Epic) containing one or more issues, all of these are then closed simultaneously. The agent may also choose to notify the individuals involved at this stage.

Now let’s examine in closer detail how these automation solutions were constructed and how they work.

Automation 02

This is a scheduled automation that runs every 10 minutes. Its purpose is to find open service requests without epic links and link them to the corresponding epic based on the ITSEC spam label field.

Be aware that if automation 02 goes into error, this may not be a problem unless it happens repeatedly. In some cases, when dealing with a high volume of issues or it runs at a very “unlucky moment”, the automation may fail on the first attempt; don’t worry however, it will link the case to the relevant Epic on the second run.

The logic behind automation 02 requires that the ITSEC project not contain identical unresolved Epics simultaneously!

Automation 03

This automation aims to assist agents in efficiently closing a high volume of cases.

Agents will now only be able to close issues of type Epic. Closing SRs will no longer be allowed for them. Once the Epic issue is marked as ‘resolved’ by the agent, automation 03 will automatically close all the child issues under it.

At this step, the agent is presented with a screen that enables them to choose whether or not to send notifications to all email addresses listed in the “Reporter email” custom field of each child issue.

Let’s see the result on a Dashboard

To highlight the overall value of the solution, a dedicated dashboard is a great option to display the status of recent incoming alerts in a single view.

This enables agents to concentrate on both the most recently entered cases (as indicated by the “Updated” column in the image below) and the most frequently recurring cases from the previous period (as shown by the “Child issues number” column). It’s important to note that while the dashboard displays a few dozen cases related to updates from a single day, it actually provides a concise overview of activity across more than 1,000 alerts from third-party systems or colleagues’ mailboxes.

Therefore, the dashboard allows agents to manage numerous cases by focusing on Epics only.

The example above illustrates how Epics can be used to consolidate similar cases that have already been addressed and integrated in accordance with the aforementioned logic. Hence, agents are required to analyze only the most urgent and/or recurring cases from that dashboard. As I said above, by solely piloting operations from an Epic itself, they’ll be able to handle multiple related cases from a single point.

Conclusions

The example we just saw is yet another illustration of the value of automation in implementing ITIL principles such as “Optimize and Automate“, “Focus on Value“, “Keep it simple and practical“, and even “Collaborate and Promote Visibility“.

As always, we advise against using this post as a reference to just replicate the solution in identical or near-identical scenarios! Instead, we encourage you to use your imagination to identify where a similar solution could benefit your team’s day-to-day operations and bring value to the end users.

It’s essential to implement these solutions wherever possible, including training agents on how to use them effectively. Ultimately, agents and the automation must work together as a “team” to ensure users derive value from the solutions.

I hope this information is useful to you. Thanks for your time, and I look forward to sharing more in the next post.

These Solutions are Engineered by Humans

Did you find this article interesting? Does it match your skill set? Our customers often present us with problems that need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.