Hi.
I have an automation rule on a Jira Service Management using an if/else block to change the label field based on the request participant field, which populates based on an email alias used to receive requests to the project e.g:
There are 4 if/else blocks in total.
This rule "succeeds" around 50% of the time and takes no action the other 50%. As far as I can tell there doesn't appear to be a patter for the reason no action is taken - it doesn't seem to depend on the participant or label for example.
Has anyone based automation on the request participant field and encountered any problems?
Hi @Nick Read
For something like this with complicated if/else conditions, I suggest posting an image of the rule to provide some context. That may help the community provide you with ideas. Also...
Best regards,
Bill
Yep, screenshots would help.
But since I like guessing... :-}
You mention IF-ELSE blocks, but when you transcribed your rule, you only mentioned IFs. In "normal" languages, all of the IF blocks would execute.
In Automation Rules... not so much. Basically what can happen is that if you don't explicitly use an ELSE, then when one IF succeeds (OR fails), the whole rule can stop processing. Also, they can execute in any order. That's probably an even bigger issue. Bottom line: It's weird.
So here's how you'd need to code it:
Doing it like below would cause unpredictable results like you're having:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ahhhhh @Darryl Lee that looks like the one! The rule was indeed like you suggested (first pic), so I changed it to include the ELSE's (second pic) and on an initial look it seems to be working much more consistently. I'll try a few more tickets to test it out now, but looks very promising.
Second one:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sidenote: I couldn't get the field condition check for Request participants to match an arbitrary email address, only already existing accounts.
Oh, are you using Advanced compare condition? If so.... that might get tricky because Request participants is a multiuser field, so you'd have to treat the Smart Value of {{issue.Request participants}} as a list, so something like {{issue.Request participants.last.emailAddress}}. And you may or may not need to put double-quotes around "Request participants".
As @Bill Sheboy points out, adding log actions would be super-helpful as well to see what fires when. You can also put Smart Values in logs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.