nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Trigger automation based on e-mail recipient

Olof Nysten_z2sv50

I have issues coming into several e-mail addresses, which are then forwarded to the JIRA e-mail. Is there any way to create an automation around that?

Example: All e-mails sent to gdpr@company.com should be forwarded to the person responsible for GDPR.

Accepted answers

All comments

Jack Brickey

Do the from emails resolve to the Reporter or in some manner captured in the created issue? If so then you should be able to use Automation to assign them based upon that info.

Olof Nysten_z2sv50

Do you mean if the original recipient is shown as sender in the received e-mail in JIRA, then the answer is no. The original sender is shown as sender. The forwarding service forwards the mail as-is.

Jack Brickey

no I meant the original sender is maintained which it seems to be the case. So the original sender is recorded as the Reporter of the issue, correct? If so then automation would be something like this...

trigger - issue created

condition - if/else block inspecting reporter (issue field condition Reporter = xxxxx)

action - assign issue based on reporter (edit issue assignee)

each reporter would have a condition and action

Matthias_gpgg4j

I think I have a similar query here. We have several email ALIASES all redirecting to the same email INBOX. This inbox is connected to Jira Service Cloud that creates a new issue/ticket for each new email received. eg. support@ourdomain.com and gdpr@ourdomain.com both redirect to the same inbox/Jira email handler.

We would like to create an automation rule based on the recipient (not the sender) of that email (eg. if recipient = gdrp, do this, else if recipient = support, do that)

I doubt it is possible without using a mail handler extension but maybe there is a workaround?

Rus Yates-Aylott_mlva9h

OK all.
There IS a way to solve this.
So... firstly you can interrogate the email logs using an API call from within an automation. This can be useful in many ways, such as responding to Failed emails etc.
The web Request should be formatted like this:
https://destinygroup.atlassian.net/rest/jira-email-processor-plugin/1.0/mail/audit/process/CHANNELdefa82dab753?from={{epochtimestamp}}&statuses=NEW%20REQUEST

Explanation:
The CHANNEL and ID are pulled from the logs using the Inspect or Console browser tool. You'll need to do this manually once for each message so you can build your rule.
The epochtimestamp is created within the automation to the period you wish to search from.
The statuses are the stauses of the log messages where 'NEW REQUEST' is a successful email that has created a valid ticket.

So now you can build your automation like this;
Screenshot 2024-10-30 081948.png Screenshot 2024-10-30 082059.png
So the epochtimestamp here is set to 1 minute before now (in order to search the logs for the past minute)
Screenshot 2024-10-30 082229.png
Now we issue our Web Request. Here's the configuration:
Screenshot 2024-10-30 082347.png
Now, for each email address you will need to branch out to perform some tests:
Screenshot 2024-10-30 082546.png
What we are doing here is creating a variable called webKey from a value captured in the webResponse by branching on the webData field:
Screenshot 2024-10-30 082842.png
Screenshot 2024-10-30 083001.png
Now you have extracted an issue.key from the response of your Web Request, you can compare it to the actual issue.key of the Trigger issue.
If it's a match you can perform an action such as enter a value into a custom field to identify a Support Queue.

As mentioned, the above, you need to repeat the branch for every email address, which means you also need to repeat the WebRequest using a different Channel ID.

This works well albeit being a tad 'clunky'.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-service-management-cloud

jira-service-management