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; } } }

Smart Value: Connected email accounts

Gerda De Lima

Hi,
I would like to set up an automation to process requests received from different connected email accounts. However, I’m unable to find a suitable smart value to achieve this.

E.g.

Request received via Option1@tomra-emea.atlassian.net are assinged to me and via Option2@tomra-emea.atlassian.net are assigned to Tobi.

Any idea? Or work around?

Thanks!

Accepted answers

James Gamble

Hola Gerda,

There is a smart value for this, but it is not one of the obvious issue fields. Atlassian has a KB for identifying which JSM mail handler created a request, and it lists this smart value:

Reference: https://support.atlassian.com/jira/kb/identifying-which-jsm-mail-handler-created-a-request/

That should return the mail handler / connected email account that processed the incoming email.

I would set the rule up like this:

Trigger: Work item created
Action: Re-fetch work item data

If / else block:

If:
{{issue.properties."request.channel.email.source".value}}
equals
Option1@tomra-emea.atlassian.net

Then: Assign the work item to Gerda

Else if:
{{issue.properties."request.channel.email.source".value}}
equals
Option2@tomra-emea.atlassian.net

Then: Assign the work item to Tobi

I would also add a temporary Log action first so you can confirm exactly what Jira is returning before building the conditions around it:

That way, you can copy the exact value from the audit log and avoid small mismatches in capitalization or address format.

Note, Atlassian says this smart value does not work for System incoming mail or aliases, so if one of the addresses is an alias rather than a connected mail handler, it may not return what you expect. In that case, using different request types per connected address is still a decent fallback. Atlassian’s multiple email address documentation says each connected email address can be assigned a request type, and incoming emails to that address are created with that linked request type: https://support.atlassian.com/jira-service-management-cloud/docs/connect-multiple-email-addresses-to-your-service-project/

So I’d try the smart value first, log the result, and use separate request types only if that property doesn't expose the address you need.

Thanks,

James

All comments

Bill Sheboy

Hi @Gerda De Lima -- Welcome to the Atlassian Community!

For a question like this, context is important for the community to help. Please post the following:

an image of your complete automation rule in a single image for continuity
images of any relevant trigger / actions / conditions / branches
an image of the audit log details showing the rule execution
explain what is not working as expected and why you believe that to be the case

Thank you, and kind regards,
Bill

Gerda De Lima

@Bill Sheboy there are not so many more details I can give:

Context:

- Transport damage claims are received by sending a mail to the connected email accounts of my JSM Service Board (screenshot 1).

I want that when a work item is created, filtered on from which email account it was received certain actions are triggered, e.g. set me (test1@email.atlassian.com)as an assigne or set my collegue Tobi as the assignee (test2@email.atlassian.com).

I am missing the smart value in order to differentiate between the accounts.

Workflow example in screenshot 2.

Bill Sheboy

@Gerda De Lima -- Thanks for the rule images, and...

Please try to stay within one thread when responding. That will help others reading the question in the future know if there are multiple solution approaches. Thanks!

For the rule you show and the scenario:

First, the Work Item Created trigger has racetrack timing problems...and thus the rule can start running before all data is ready. This can cause errors and weird rule behaviors. To mitigate that:
- Always add a Re-fetch Work Item Data action immediately after this trigger
- Never use conditions directly on triggers; instead add separate conditions after the re-fetch
Next, when you want to alter the behavior based upon something in the rule data, add an if / else condition block. In this case you could check the Description or the Reporter fields. However...
- I recall that after adding Connected Email Addresses, people noted it was not possible to easily distinguish them within automation, and instead required creating separate request types for each address.
- Perhaps first try using conditions to check the reporter to see if that works

James Gamble

Hola Gerda,

There is a smart value for this, but it is not one of the obvious issue fields. Atlassian has a KB for identifying which JSM mail handler created a request, and it lists this smart value:

Reference: https://support.atlassian.com/jira/kb/identifying-which-jsm-mail-handler-created-a-request/

That should return the mail handler / connected email account that processed the incoming email.

I would set the rule up like this:

Trigger: Work item created
Action: Re-fetch work item data

If / else block:

If:
{{issue.properties."request.channel.email.source".value}}
equals
Option1@tomra-emea.atlassian.net

Then: Assign the work item to Gerda

Else if:
{{issue.properties."request.channel.email.source".value}}
equals
Option2@tomra-emea.atlassian.net

Then: Assign the work item to Tobi

I would also add a temporary Log action first so you can confirm exactly what Jira is returning before building the conditions around it:

That way, you can copy the exact value from the audit log and avoid small mismatches in capitalization or address format.

So I’d try the smart value first, log the result, and use separate request types only if that property doesn't expose the address you need.

Thanks,

James

Gerda De Lima

Hi James, thanks a lot! This is exactly what I was searching for! :-)

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management