Automation rule error when changing label field based on request participant field
Asked by Nick Read:

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?


Answers:
author: Bill Sheboy
body: Hi [@Nick Read](/t5/user/viewprofilepage/user-id/3710352)

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

comments: author: Darryl Lee
body: 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](https://community.atlassian.com/t5/image/serverpage/image-id/136649i22D3C089EF6F333D/image-dimensions/178x412?v=v2 "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.png](https://community.atlassian.com/t5/image/serverpage/image-id/136650i1A553813742D32C7/image-dimensions/228x444?v=v2 "Screen Shot 2021-03-30 at 11.26.39 AM.png")![Screen Shot 2021-03-30 at 11.28.59 AM.png](https://community.atlassian.com/t5/image/serverpage/image-id/136651i8A14A0EECC1C331F/image-dimensions/221x295?v=v2 "Screen Shot 2021-03-30 at 11.28.59 AM.png")


author: Nick Read
body: Ahhhhh [@Darryl Lee](/t5/user/viewprofilepage/user-id/1365322) 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](https://community.atlassian.com/t5/image/serverpage/image-id/136738i15EC41A59492DCC6/image-size/large?v=v2&px=999 "Screenshot 2021-03-31 at 09.16.54.png")

Second one:

![Screenshot 2021-03-31 at 09.17.05.png](https://community.atlassian.com/t5/image/serverpage/image-id/136739i1025ABBCDADEBB6B/image-size/large?v=v2&px=999 "Screenshot 2021-03-31 at 09.17.05.png")


author: Darryl Lee
body: 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](/t5/user/viewprofilepage/user-id/1685313) points out, adding log actions would be super-helpful as well to see what fires when. You can also put Smart Values in logs.


Tags: cloud

jira-service-management