You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I was changing an existing rule to add a few checks to limit the amount of "Success" executions. And I was puzzled at first. It turned out that a ticket matched the If-block, automation changed a custom field to a value that made the Else-if block match while at the start of the execution it didn't.
Now, I'm not a programmer, but I would have expected that if the If matches, it would stop evaluating Else-if. Which is not the case here.
So I was wondering, is this by design, or not? :)
For a question like this, I recommend posting images of your complete rule (in one image) and of the audit log details showing the rule execution. Those will provide context for the community to offer suggestions. Thanks!
Until we see those...
Conditions in rules have two possible impacts on processing: stop or keep going. And so the structure of the rule and conditions is important. For example:
In this case, the action only happens if the condition is met.
For this one, only A or B or C will happen, followed by D happening.
Now here is a sometimes confusing part: rule processing is based on the issue data from the time the rule triggered. And so if in the above case, "some action B" changed the issue data, those changes are not visible to the remainder of the rule. When we want the changes to become visible to later processing, we add a Re-fetch Issue action to reload the data before continuing.
Other rule structures impact flow also, like this one
In this case, condition 1 does not stop rule processing if it is not met...because it is contained within the branch. Instead it just stops further branch processing for that loop.
Again, seeing your rule structure will provide context to help explain what you are observing.
Well, it's like this:
Custom Field is set to False
What happens is this:
If matches, because the field is set to False. Action taken: custom field is now True.
Now I would (like you) expect the rule processing to stop. But it doesn't. It goes to the else-if and says: ah, Custom Field is not set to False (it was changed to True in the If block), so I need to set to False. Which was not the intention at all!
So this tells me that rule processing does not use issue data from when the rule was triggered. And that not A or B happen, but both!
This is what the rule looked like:
This is what the execution looked like:
How I solved it:
Custom Field is set to False
So I added a new condition to the Else-if so that it would not match the state that was created in the If-block.
I hope this made sense :)
It appears there is some image capture issue with your rule. Regardless...the rule image you show does not match the text description of your rule:
I wonder if there was a problem with the initial rule conditions.
I was wrong. Explaining the whole logic to you and diving deeper into it helped a lot in finding my error :)
The first If block was not hit, because a new condition was added. And because it was not hit, the Else-if was hit, while it shouldn't have been.
Thanks a lot for your time!