1bbfd485bf63 is there a release date for this feature on the roadmap of this year? 

This is needed to capture visibility up-front if an email notification fails to send.

1bbfd485bf63 Is it possible add a flag when viewing issue detail, if previous notifications failed to send to a reporter or request participant?

Great news Ben, thx for the feature.

Hope it is in the earlier first half of the year

Cheers

Awesome news!

Dear Santa Atlassian

 All I want for XMAS is JSDCLOUD 2517 and ACCESS -822

Thankyou Ben

JSDCLOUD-798 now implemented ( a good one) any news on expected ETA on this? 

https://getsupport.atlassian.com/browse/PCS-346598

Exactly what Rebecca said. We are in the same position and need a solution.

Agree that this would be a useful feature!

Are there any updates on this? 

In our case, we do not allow email ticket submissions if the address is not signed up as a Customer, this causes a failure. This is an intentional decision as Customers who are signed up with service desk are required to be Administration Users and trained on the system.

It would be very useful to be notified when this does occur as our customers will sometimes share the support email address among their team without realising the conditions set for being able to submit the ticket, so we can miss some tickets leading to a potentially unhappy customer who thinks we are ignoring them.

To be alerted of these means we would be able to promptly address these rather than finding them weeks or months down the track when Email Logs might be checked.

Thanks for resolving https://jira.atlassian.com/browse/JSDCLOUD-798, 1bbfd485bf63! Does this mean this issue is moving from "Under Consideration" to "In Progress" soon?

poye, As the indicated JSDCLOUD-798 is already rolled-out (and working fine), can you update current situation on this one?

+1

This is desperately needed. If it isn't possible to configure an alert natively, I would happily settle for the log to be a trigger for Automation.

If the bug is not corrected for more than 3 years I don't understand why the feature that would allow to control this gets prioritised.

Hello, this feature is very important and it feels like a basic reuqest to implement. Voted for implementation and looking forward to prompt action. 

BADLY NEEDED

Hi, any news on this?

Thanks

They're too busy fixing all the security bugs to add any new features!

Any updates on this? A big hurdle to our CS-team ... 

Shocked post migration to see Jira Cloud has more limitations than Jira Server.. this is one of many items which are a pain point now since the migration. What were Atlassian doing when they scoped out stopping server?? so so poor. 

This feature should have been there from the start. Manual checks is not good enough. 

This 'feature' is business critical and the workaround is not ideal, mail handler failures cause major disruption to our customer support.

It's very sad that this function hasn't even been implemented yet. It's happened to me twice now, and it's affecting operations and our customers. It's not normal that we have to look at connectivity logs manually for tickets that have failed, we have other tasks and things to do in our respective companies than look at email logs.
Our customers' operations are 24/24, we can't afford for the logs to stop working.
please find a solution quickly, it's not a luxury to have this function/option but a need that many of us have in order to serve our company and our customers well.
PS: there should be at least one update every month of this post, the last comment was in September 2023, it's already been a few months that we have no response on this issue.

Thank you

Hi,

it's been 3 months, any news on this one? It is quite an important feature for most JSM users.

Thanks

Hi everyone,

For my team this functions is very important. We are big company,the leader in logstics in Bulgaria. The hole comunucation with clients goes trouth Jira. For us is very important to receive notifications when messages are not send to clients or our team dont receive it. 

I hope this improvement will be implemented soon. 

It honestly makes no sense that such a basic feature is taking such a long time to implement. It should be very simple to implement something like this. You already have a trigger, "Status=Failed", so when that happens, the admin of the project (at least) should be notified. How hard can this be? You have probably spent more time and man-hours on saying No, considering this but later, 3-6 months, whatever than the time that it actually takes to develop such a feature.

Update 13th September, 2023

Hi everyone,

We had to postpone picking up this feature as we are working to ship https://jira.atlassian.com/browse/JSDCLOUD-4698 and https://jira.atlassian.com/browse/JSDCLOUD-6037 to make email experience better. We will be revisiting this issue again in another 3-6 months.

If you feel this feature is important to you, please feel free to reach out to me at msingh10@atlassian.com. I would love to get more insights as we plan for this item in our roadmap.

Thank you for your patience.

Cheers,
Manpreet and the Jira Service Management Team

In 2021 you said "This issue is the next item on our roadmap." Would be great, if we could get an update on this.

Hi,

is there an API for retrieving failed mails?

This is really painful to monitor manually often.

Best regards, thank you, Nena

Not a bad solution if the notification is required by an Administrator but, not so useful if attempting to send a notification back to the original sender.

@Eva Have you considered deploying the workaround (https://community.atlassian.com/t5/Jira-Service-Management-articles/An-unofficial-way-to-monitor-a-JSM-mail-handler-for-errors/ba-p/2132002)? It is of course not a fix, but it will notify you of rejected messages and thus mitigate the issue. 

I note most comments on this topic are from 2022 or earlier. Here we are in August of 2023 and I am facing the same issue as many have reported before. Emailed requests that fail for any reason sit there without action because the sender is not notified of any issue. In turn, this reflects badly on us because it looks like we are breaching our SLA policies.

Has this gained any traction at all?

Big reliability flaw that seems to be easy to fix.

If an email fails to be processed, email the project admins.

Looks like people have been waiting since 2015:

Thanks Pam, that is really useful to know about Zendesk - I've never used it, but have been considering alternatives to JIRA.

The equivalent capability is provided by Zendesk. It seems like a must-have to me.

I think there's actually a problem with the way Access Management is configured. It does not allow for this type of set up:

1. email requests can be accepted from anyone (as long as it meets the Allowlist / Blocklist criteria), and separately
2. portal access is invite only (.e. self-sign up for Portal is disabled but DOES NOT affect ability for users to send email request  - they just can go to the portal to see their submitted issue)

We want to use a company wide generic support email e.g support@mycompany.com but not allow users to access the portal unless they are part of a domain (or perhaps by invitation only).

Currently if we set up self-sign up on the Portal to specific domains, we would not be able to receive email from legitimate users who find our support email address organically on our website , or on some brochure. But we do want to respond to them by email - but not allow them access to the Portal and via Portal the Support Knowledge base for customers.

Currently this is NOT possible. 

As a workaround we should at least be notified of emails that have status fail so the Admin or Lead agent can do something about it. Zendesk allows you to manually promote the blocked email to an ticket.

@Nina Vehovec

i am still waiting since 2019

Is there any update on this?

Best regards, 

Nina Vehovec

Hi, I have just written a question in the community about Youri's workaround:

"It would save us time and these checks could be done more often then now. 

We will try it (hoping soon). But what about security? How secure is this - can someone intercept traffic and misuse the information somehow?"

Hi, description says "We have shipped https://jira.atlassian.com/browse/JSDCLOUD-2373 and are currently developing a solution for https://jira.atlassian.com/browse/JSDCLOUD-5878 . This issue is the next item on our roadmap.". So JSDCLOUD-5878 is now closed - so where is the ETA on this issue?

Hi Yuri, how do I restrict the rule so that it only includes recent failures - I've got the rule working but it keeps repeating the same content in the list in the email and I want to be able to exclude addresses that, have subsequent to a previous alert, been added as customers so we don't get the same alert multiple times!

Thanks

We are also impacted by this. We restrict some of service desks to customers only and those get blocked silently as well have ran into random authentication errors with Office 365 that cause all emails to not process and we had no clue until we were CCed on a support email.

Fully agree for emails on restricted board to still create the issue but require CSR action to create the customer to process the request. 

Also any sort of email failures should be an admin email notification. Under Jira System Settings -> Incoming Mail there are Mail Handlers you can setup with have failure notifications. I tried to setup a Mail Handler to handle all inbound email for a specific restricted service desk but every way i tried it fails for a mail loop. 

I've had to make all my agents administrators so they can view unsolicited/rejected messages. This ticket is not assigned to an active product manager?

I too would like the functionality of either an email sent to specific groups/users or an Issue get autogenerated. Preferably with features to determine how we would like to be notified. I did try Yuri Moura's suggestion and was not able to get this to work. As in, the rule claims to succeed but I am not receiving any emails about failures even when there is one.

Hello everyone!

I created a community article that can help most of you to implement this within Jira with Automation and API:

• Monitoring a JSM mail handler for errors

I hope this helps! 

I also agree with these comments made recently.

The fact that all emails may fail made us (unwillingly) to set the customer perimmsion for a service project to be open/global so that all emails process correctly, whereas what we needed was that the ticket to be created and give the option to the agent as to whether the account is genuinely customer or not. As a result, many emails (e.g., Google Drive notifications or mailing lists) generate accounts in our instance. 

I understand that team should separate the support email channel with other purposes in using email (aka mail list, app notification), but in reality, it is not very practical, and things happen, and we are not equipped to handle those exceptions.

This is one case where the email may be failed to be processed, but an important one.

I agree with Jawann/Peter, having unsolicited emails come through as unassigned/nominated account would be ideal. That way agents don't have to monitor a queue nor have to then add the customer and go into the support mailbox to mark it as unread. Previously on Jira Server I wrote a basic sql script to get failed sign ups and generate a daily email to our team for action. I haven't yet investigated if this is possible through Jira Cloud API.

Edit: infact, the ideal scenario would be:

1. create the email as an issue
2. reporter = customer in an unapproved state
3. agent can verify if the request is genuine and either:
   1. assign to someone else int he customer's organisation or
   2. click 'add customer' within the ticket

I had reached out to support and had Christian send me the link for this issue. 

Twice within the last month or so, there have been issues with the connectivity of our custom email within our project causing tickets to not be generated by incoming emails. There is no way to know if the email is having issues without going into the project settings themselves. 

I feel like all the moving parts are already there as the notification pops up as soon as you go in to the email requests, however there is currently no way to turn that into a notification either as soon as you log in to your project, or (more ideally) to send an email with the error. 

The client I manage this for is dealing with pretty high caliper things that could cause huge issues if their support tickets are not handled according to their SLA's. Kind of hard to do when a ticket is not even being generated!

Great point by @Peter Dunham. The ideal solution would be to have external emails still create a Jira issue with a default reporter (maybe Automation for Jira?), but not create an account for the external user.

Just as an FYI, our solution for this is to have our JSM email address inside a distribution list that can accept external emails. We have a couple of users who are also members of the distribution list and have filters set up to catch the external emails.

We also need this sorted, only just discovered this issue and the log doesn't go back till the start. Who knows what we might have missed.

I would like a propose a reframe of this requirement.

Instead of saying our team would benefit from "Notifications for incoming emails that fail to be processed" , what would work better for us:

Requirement Reframe:

• Allow "Customer Permissions" to equal "Customers added to this service project only by agents and admins"
  • While still allowing all email received from non-customers to still generate a Jira Issue
    • In these cases allow a default assignee or make it project lead
    • provide some messaging that comments will not be seen by customer unless reporter is updated or added to the portal

Currently, these settings are coupled together which causes email to fail.

My team does require "Customer Permissions" to be set to restrict access to portal but we still want all emails to be generated in to JSM issues.

Note: This functionality is somewhat implement in Jira Software if an email handler is setup to receive email and create tickets

agreed - I am paying someone to monitor this failed email queue, totally bonkers!

Atlassian,

Seriously... the log exists. We just need the most rudimentary way to get an alert for rejected. Allow us to have rejected send to email. Even if it is not immediate, anything is better than nothing. Last update was half a year ago. I am a couple of months in as a customer and this is still my biggest headache. I am still paying one of your competitors for a small number of seats because it's the only way I can be sure that we don't miss requests. This is utterly ridiculous.