Using email aliases to route tickets

[Justin Cruz]

I cannot seem to get emails to consistently run with the automation as outlined in this support article:

https://confluence.atlassian.com/jirakb/using-custom-mail-handler-aliases-to-route-incoming-requests-1142247777.html

The end goal is that if an email is sent to a particular alias, it would then get marked in the service desk as a particular request type. The goal is that the service desk would be across departments since there is some shared information and actions that need to happen within it (so we'd prefer not to make seperate projects).

Having followed this article exactly and have tried different variations of it, and typically 1 out of every 10 messages will correctly run through the automation.

I understand that there are tools like JehmCloud however we're trying not to bring on anything else, and use our existing tools, especially since Atlassian has this as the reccomended way to approach this.

If anyone has any reccomendations or experience with this it would be appreciated.

[Trudy Claspill]

Hello @Justin Cruz 

Welcome to the Atlassian community!

The article provides an example of simply editing the issue fields rather than changing the type of the issue.

Can you please show us your full automation rule?

Can you show us the Audit Log for an execution of the rule that you think should've changed the type but did not?

[Justin Cruz]

Thanks @Trudy Claspill for the insight. Maybe I was over thinking of what that automation was capable of and scaled it back to just do a single edit/change then for a component instead.

I've deleted and remade the automation and mail handler to see if that would effect things, but this continues to be the behavior in the screenshots.

Once in awhile it would update/change the incoming ticket and properly format it.

[Trudy Claspill]

To what is the Reporter field being set when the issue is created?

Can you show us the configuration of the mail handler?

From whom is the email actually being sent?

The information in the Audit Log is essentially saying that the Reporter of the issue is not set to the user ittest so the remainder of the rule was not run for that particular execution of the rule.

[Justin Cruz]

The Reporter field is set as the IT Test user that matches with the alias.

Mail handler settings in this iteration. I've tried it before without the Default Reporter being set as well and it give the same behavior.

My user account has been the one sending to the alias to try and kick off ticket creation.

[Trudy Claspill]

The Default Reporter is used only if the actual Sender's email address doesn't match to an account and Create Users is unchecked.

Looking directly at ITOPS-124, who is listed in the Reporter field?

[Justin Cruz]

It lists me as the reporter.

[Trudy Claspill]

That is your issue, then. The rule only works if the Reporter is set to the user ittest, and the mail handler will only set the Reporter thus if the sender's email doesn't match to a known account.

Is there a reason that you opted to try to work the rule based on Reporter rather than Request Participants as suggested in the article?

I notice that the article and the links provided don't actually detail how to configure the mail handler. That is a gap in the explanation. And they are not saying exactly how the support-alias@yourdomain.com address is getting added as a Request Participant, to be found by the automation. I've not ever set up an additional custom email on a Jira Cloud Service Management project, nor set up aliases in an email server before. Maybe it is self evident if you have the knowledge already.

[Justin Cruz]

Thanks for pointing that out. I've recreated the automation so many times at this point that that was most likely a typo.

When I've initially set it up yes I was using Request Participant as per the article, and in the other variations of the automation for the other aliases. It's still the same behavior however. This morning to make sure I wasn't going crazy I updated the automation to ensure it's Request participant and it did the same thing.

Yes you're right, that is 100% lacking from Atlassian's documentation which seems to be on brand. It feels like they over complicate things when really they should just have a way of seeing an incoming email address and base it off that and not have it be reliant on customers/accounts. It is what it is. I have a ticket open with Atlassian as well, so we'll see if they provide any insight.

[Constance Kan]

Hi @Justin Cruz

I am actually facing the same issue with you right now. Did you get a response from Atlassian regarding this matter?