Send email to unique email address based on the random selections made in multi-select custom field

[VVC]

Would it be possible to setup an automation rule for sending an email to an unique email address for each option(s) selected randomly in a multi-select choice custom field in Jira DC?

I have a multi-select choice field "tags" with 10 option values in a Story issue type. Now whenever user makes a selection either one value or multiple values then Automation should send out an email accordingly.

Custom field name: Tags

Options: A, B, C, D, E, F, G, H, I, and J

Corresponding Emails: Option A -> A1@gmail.com, Option B -> B2@gmail.com, Option C-> C3@gmail.com, Option D -> D4@gmail.com, Option E -> E5@gmail.com, Option F -> F6@gmail.com, Option G -> G7@gmail.com, Option H -> H8@gmail.com, Option I -> I9@gmail.com and Option J -> J10@gmail.com

My current automation rule is not working as expected.

Trigger: Field Value changed

If Condition: tags equals A then send email to A1@gmail.com

Else if: tags equal B then send email to B2@gmail.com

and so on till Else if: tags equal J then send email to J10@gmail.com

This automation rule works only for a single selection in tags field and if I select more than one value then this rule fails obviously. Now rather listing all combinations and permutations inside this if condition loop, would it be possible for automation rule to send all corresponding emails for any number of options selected inside the tags field randomly?

[Bill Sheboy · Accepted solution]

Hi @VVC 

First, here are some questions to clarify the scenario you are trying to implement:

How many different email body contents are there: one to send to everyone or a different one for each recipient?

When do you want to send the emails?  That is, every time the field changes send an email to each selected recipient, or something else?

What does the "random selections made" mean?  Do you mean any values could be selected, or that there is some actual randomizing happening?

Until we know the answers to those questions...

With the if / else block in rules, one-and-only-one of the choices is selected.  It does not process each entry which meets the criteria.

Jira Data Center's version of automation does not support the Lookup Table or Advanced Branch features yet.  Thus your workaround options depend on the answers to the questions above.  A couple of options are:

• When there is a different email body for each recipient, this makes for a long rule, with branching added: branch to current issue, test the field with a condition, send the email.  That is repeated 10 times.
• When there is one email body which is sent to multiple recipients, try a conditional expression with list iteration to create the list of recipients in a variable.  Then send one email to them all.

Kind regards,
Bill

[VVC]

Thanks @Bill Sheboy  for asking these questions and see below for my response. Please let me know if this helps further to draw a concrete solution.

How many different email body contents are there: one to send to everyone or a different one for each recipient?

VVC: About 7 option values has same email body contents, while the remaining 3 option values have different and unique email body contents. Each recipient is different, so each one has unique email address. In other words, 7 recipients has same email body contents, while the remaining 3 recipients has different email body contents.

When do you want to send the emails?  That is, every time the field changes send an email to each selected recipient, or something else?

VVC: Email(s) should be sent out to each unique recipient as soon as the field value changes in the ticket.

What does the "random selections made" mean?  Do you mean any values could be selected, or that there is some actual randomizing happening?

 VVC: Any value or multiple values could be selected randomly based on the internal business process on this multi-select choice custom field called tags.

[Bill Sheboy]

Based on your answers, the rule could use first approach I described with branching.  For example:

• trigger: field value changes
• branch: on current issue
  • condition: the field contains "value A"
  • action: send the email to A's recipient
• ...repeat for all of the possible values

As I noted earlier, this would send an email to each selected value's recipient every time the rule runs.  If you instead only want to send the email once, some indicator must be saved (such as with another field) to detect the email was already sent.

[VVC]

Bill, I have been trying few different ways to get this working and if I remember correctly, the condition field contains "value A" works which sends the email once. But when selecting multiple values randomly either during the ticket creation or ticket update operation, the emails to the individual recipients doesn't work.

[Bill Sheboy]

The trigger for field value changes only fires when an issue is updated.  When you want the emails for Issue Created also, the rule will need to be duplicated to use that trigger.

For an issue update which does not send the correct emails, you would need to research that for each case to determine the cause.  Note that if you leave the field when selecting the values, that will trigger the rule each time the field changes.

And once again, without seeing images of your complete rule and the audit log details, these are just guesses.  I recommend trying what is described above to learn what helps.

[VVC]

The if, else condition with Advance compare two values seems like a good fit so far. I would also like to extend the automation to stop sending email if a pre-existing option is unselected at any point. Is there a way to stop the notification, if an existing option is unselected?

[Bill Sheboy]

Wouldn't that take care of itself?  That is: when the value is not selected that email would not be sent.

[VVC]

When A, B & C option values are selected in a tag (multi-select) field then an email goes out to the respective email address. Let's say that you edit the ticket and unselect the existing C option value then email goes out to respective email address for A & B options.

Any ideas or suggestions to tweak my automation rule to stop sending emails when an existing selected option value is unselected?

[VVC]

Any ideas on how to stop sending emails when an existing selected option value is unselected?

[Bill Sheboy]

Yes: do not use the change log and instead please test each case as I noted earlier.

• trigger: field value changes for Tags
• condition: issue type is Story
• branch: on current issue
  • condition: Tags contains Benefit Changes
  • action: send the appropriate email
• branch: on current issue
  • condition: Tags contains Configuration
  • action: send the appropriate email
• branch: on current issue
  • condition: Tags contains Testing
  • action: send the appropriate email

Thus if a value is not selected it will not be found in the Tags and the email will not be sent.  However, this rule will also send all found value emails each time the rule runs.

[VVC]

Bill, I have already tried your suggested automation rule but it still doesn't work as expected. Instead, this logic does send a repeated email for existing selected tag options besides an email for the new selected option.

When deselecting existing option(s), an email goes out for the remaining tag option(s) owners. I have also tried adding Advance compare condition along with Re-fetch issue data action but still no luck at all.

[Bill Sheboy]

Let's pause to confirm your scenario: do you want to send emails only for the added Tags?

In that case, the rule can only be done if you have the Create Variable action in your Server / Data Center version (or with Jira Cloud).  Do you have that in your version of automation rules?

If so, let's first create a test rule, using the change log and a regular expression to try to identify the added Tags.

• trigger: when value changes for Tags
• action: create variable
  • name: varFromString
  • value: 

{{#changelog.Tags}}{{fromString}}{{/}}

• action: log action
  • varFromString: {{varFromString}}

• action: create variable
  • name: varPreviousTags
  • value: 

{{varFromString.split(" ").join(",")}}

• action: log action
  • previous Tags: {{varPreviousTags}}

• action: create variable
  • name: varCurrentTags
  • value: 

{{issue.Tags.value.join(",")}}

• action: log action
  • current Tags: {{varCurrentTags}}

• action: create variable
  • name: varRegularExpression
  • value:

{{#if(varPreviousTags.length().gt(0))}}^((?!({{varPreviousTags.split(",").join("|")}})).*){{/}}{{#if(varPreviousTags.length().lte(0))}}(.*){{/}}

• action: create variable
  • name: varAddedTags
  • value:

{{varCurrentTags.split(",").match(varRegularExpression)}}

• action: log action
  • added Tags: {{varAddedTags}}

Now test the rule, adding and removing values for the Tags field on an example issue.  Review the audit log after each test.  If the varAddedTags contains only the added ones, it can then be used with the earlier conditions to test and send the emails.

[VVC]

With your Variables logic, the audit log for each test is capturing the added or removed values for the Tags field. I have never used the Create Variable action logic in the past, so could you please help by showing me one example of how I can actually use it with the earlier conditions for a quick reference please?

[Bill Sheboy]

That is great news!

Now that we have the {{varAddedTags}} smart value with a list of Tags, such as:

A, B, C

You may use the Advanced Compare Condition to test if it contains one of the values needed.  This would replace the Issue Fields Condition you used earlier.

• Advanced Compare Condition:
  • first value: {{varAddedTags}}
  • condition: contains
  • second value: Benefit Changes

I recommend trying just one first to confirm it works as expected before adding the others.

[VVC]

Hi Bill, I was OOO and now back onto this one. Unfortunately, the end result was same as the automation rule still send an email when an existing pre-selected option is deselected, which is NOT desired at all.

[Bill Sheboy]

When you review the audit log, how many times is the rule triggering when you change the field: one time or multiple times?

If it is multiple times, have you confirm you are not exiting the field and so making it an edit for each change?

[VVC]

When I tried with one option, added tags variable is set to empty thus failing on the matching condition.

[Bill Sheboy]

One of the challenges of re-building something that should already work in rules is our workarounds tend to be "brittle" and challenging to test.  Oh well...let's try again :^)

Please see my earlier post as I recreated the variables to handle the different cases, and account for the possibility a changelog's {{fromString}} is delimited by spaces and not commas.

https://community.atlassian.com/forums/Confluence-questions/Re-Re-Send-email-to-unique-email-address-based-on-the-r/qaq-p/2971602/comment-id/336884#M336884

Again, I tested this with Jira Cloud and so the regular expressions may be different for Server / Data Center automation.  Here are the cases I tried:

1. empty field --> add a single value
2. single value --> remove the value to empty field
3. single value --> add one value to the field
4. single value --> add multiple values to the field
5. multiple values --> remove one value
6. multiple values --> remove all values
7. multiple values --> add multiple values and remove multiple values

Please add multiple cases to match your scenario.

[VVC]

Thanks Bill for your continued support assistance. Initially it looked like working but upon throwing multiple scenarios then it kept failing and inconsistent results. I will run a few more tests today and see how this works.

[VVC]

@Bill Sheboy You're the STAR. A few minor tweaks to your logic helped this automation to work exactly as needed. THANK YOU SO MUCH!!

• Trigger:  when tags value changes
• Action: Added Re-fetch issue data right after Trigger
• Branch (For Current Issue)
• Condition: Advance Compare ({{varAddedTags}} contains tag value)
• Action: Send email
• Repeat for each tag value

[Bill Sheboy]

I am glad to hear that helped, although I wonder...

From what you show above ^^^ in the last post, the created variable {{varAddedTags}} is referenced but is not defined.  Do you still have steps in the rule to create that variable?

[VVC]

Yes, all steps from {{varFromString}} to{{varAddedTags}} then followed by Branch, Condition and Action.

[Bill Sheboy]

Great, and just to confirm: is this question resolved?

If so, please consider marking this question as "answered" to help others with a similar need find solutions faster.  Thanks!