Help with Mail Handler & Automation for Incident Monitoring/Alerting Emails - Can't Create Comments

leonardo.penaloza
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
January 15, 2025

Hi Atlassian Community,

I’m currently facing an issue with the Mail Handler in Jira Service Management (JSM) and need some guidance. We have an email address integrated with JSM that receives two types of alerts from our monitoring system:

  1. "Fired" Alerts – These indicate when an issue is detected.
  2. "Resolved" Alerts – These indicate when the issue is resolved.

The current behavior:

  • When a "Fired" Alert email comes in, JSM automatically creates a new Incident ticket. (This works as intended)
  • However, when a "Resolved" Alert email is received for the same issue, instead of updating the existing ticket, JSM creates a new duplicate ticket. (Which we don’t want)

Desired outcome:

  • Only one incident ticket should be created when a "Fired" alert is received.
  • When a "Resolved" alert is received via email:
    • It should add a comment to the existing ticket (referencing the original "Fired" alert ticket).
    • The status of the original ticket should be automatically updated from "Open" or "In Progress" to "Resolved" using automation.
  • Ideally, the process should run smoothly without manual intervention.

Additional context:

  • Both "Fired" and "Resolved" alerts come from the same email address and include a consistent subject line pattern:
    • For example, "ALERT: [Service Name] Fired" and "ALERT: [Service Name] Resolved".
  • The email body contains unique identifiers for each alert, which could potentially be used to match the "Resolved" alert to its corresponding "Fired" alert ticket.
  • The emails do not contain any issue key, so using the standard approach of matching incoming emails based on the issue key is NOT an option for us.
  • We have reviewed documentation on this subject multiple times, but the guidance primarily refers to scenarios where the issue key is included in the email. Since that’s not feasible for us at the moment, we’re looking for an alternative approach.

My questions:

1. Do I need to make any specific changes to the Mail Handler settings to prevent duplicate ticket creation when the Resolved alert comes in?

2. How can I set up an automation rule that identifies the existing ticket based on the email subject or unique identifier in the email body and updates it instead of creating a new ticket?

3. Are there any best practices for setting up email-based incident creation and resolution in JSM to handle this type of scenario efficiently?

I’d appreciate any step-by-step guidance or examples on how to configure the mail handler and set up the automation rules. Thanks in advance for your help—I’m looking forward to your suggestions!

1 answer

0 votes
Luiz Ricardo Pereira da Silva
Contributor
January 21, 2025

Hello Leonardo, how are you?

First, it’s important to check which Mail Handler Type was configured.
For your case, a suitable option would be "Create a New Issue or Add a Comment to an Existing Issue."

Captura de tela 2025-01-22 012428.png

However, there’s a key point regarding this setup.
If the email indicating that your alert has been resolved is a standalone email and not a reply to the original alert, this solution will indeed not work as expected.

IIn this case, it will be necessary to create a new Mail Handler that converts emails into comments.
In it, we can configure:

Subject Pattern:

Configure the Mail Handler to identify existing tickets based on a specific pattern in the email subject.
In your case, the "Triggered" and "Resolved" alerts follow a consistent pattern, such as ALERT: [Service Name]. Use this pattern to map the incoming email to the corresponding ticket.

Message Handling Configuration:

Ensure that the Mail Handler is set up to:

  • Find existing tickets: Use the "Match on Subject" field and input a regex to identify tickets based on the subject pattern.

    I hope this has been helpful to you in some way.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events