Automation rule error when changing label field based on request participant field

Nick Read March 30, 2021

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:

 

  • When value changes for request participant
    • If: matches: email.one@example.com
      • Then: edit issue fields Labels to (email_one)
    • If: matches: another.email@example.com
      • Then: edit issue fields Labels to (another_email)

 

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?

2 answers

1 vote
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 30, 2021

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...

  1. Have you seen any errors in the audit log for when the labels are not updated?
  2. Have you considered adding a log action to add the Request Participant to the log to see how its value matches what you expect in the condition tests?

Best regards,

Bill

Darryl Lee
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 30, 2021

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:

Screen Shot 2021-03-30 at 11.23.32 AM.png

Doing it like below would cause unpredictable results like you're having:

Screen Shot 2021-03-30 at 11.26.39 AM.pngScreen Shot 2021-03-30 at 11.28.59 AM.png

Nick Read March 31, 2021

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. 

 

Screenshot 2021-03-31 at 09.16.54.png

 

 

Second one:

 

 Screenshot 2021-03-31 at 09.17.05.png

Like Darryl Lee likes this
0 votes
Darryl Lee
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 30, 2021

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.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events