Two conditional actions in an automation rule

[Benjamin Peikes]

I would like an automation rule that does this:
When transition to "In Progress"

if(assignee IS NOT SET) {assignee = current user}

send messaage

I always want to send a message, but I always want it sent after the assignee is set. I also want the message sent if the assignee is already set.

[Mykenna Cepek]

Here's how I would design this rule (tested, works).

Note that having just one "Send email" action that sends to the Assignee (after the conditional) will not work. Odd behavior with Automation causes the Assignee field to be blank (for a brief period of time) even after being assigned in the rule. In my testing, even a "Re-fetch issue data" action (after the conditional and before sending the email) did not clear up this problem.

This "if/then/else" approach also allows the two situations to have different emails, perhaps with Subject or Body customized to clarify the context and action that triggered the notification.

Note also that (depending on user notification configuration), the email sent here might be redundant with a built-in Jira notification that the user was assigned an issue, or that an assigned issue had been changed.

[Benjamin Peikes]

Thanks, I’ll give it a shot. I agree the threading model for automation is pretty ridiculous. They really should have just given us a language and a library to script. Then at least it would be more clear which parts were async. 

[JimmyVanAU]

Hi Ben,

Can you explain your rule a little more. It sounds like:

• if assignee is not set, then assign a user
• if assignee is set, do nothing with the assignee
• once user assigned, then trigger email

Is that right?

Could you please send a screenshot of your configuration?

Cheers, Jimmy

[JimmyVanAU]

In addition to Mykenna's answer, and using the "If/else" condition (rather than a simple condition which I suspect is the culprit for the rule not behaving correctly), I'd go one step further and follow the DRY (Don't Repeat Yourself) principle, so that if you did need to update the email, you only need to do it in one place.

Re-fetch is needed as the correct assignee is not updated straight away, and as suggested in the text:

If you need the latest state of an issue in subsequent actions in this rule you can use this action to re-fetch the issue. This action does not reload the issue in the browser for end-users.

Here's an example of an automation rule that would require a re-fetch action:

• Action: Send an e-mail to the assignee

The final rule looks like this for me (vary your When:/trigger as necessary)

[Mykenna Cepek]

JimmyVanAU suggests an approach that I tried first. It did not work for me. Be sure to test it if you want to go that route.

The problem seemed to be (as I pretty clearly stated in my answer) that the "Re-fetch issue data" action didn't renew the "Assignee" field, even if the conditional set it.

I'm guessing it has something to do with threading and race conditions (which I've written about elsewhere) that plague Jira automation and upset assumptions about sequential execution of rule components.

In my testing, a rule formed as above failed when the issue was unassigned. The "Send email" action would give an error that the Assignee field was blank -- despite the Assignee field being set once the rule was done executing.