nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Evaluating Else-if when If matches

Tom De Blende_eni1ol

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?

Accepted answers

Bill Sheboy

Hi @Tom De Blende

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:

trigger...
condition...
- some action

In this case, the action only happens if the condition is met.

trigger...
if/else condition 1...
- some action A
else/if condition 2
- some action B
else
- some action C
some action D

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

trigger...
branch...
- condition 1...
  - some action
condition 2...
- some action

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.

Kind regards,
Bill

All comments

Bill Sheboy

Hi @Tom De Blende

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:

trigger...
condition...
- some action

In this case, the action only happens if the condition is met.

trigger...
if/else condition 1...
- some action A
else/if condition 2
- some action B
else
- some action C
some action D

For this one, only A or B or C will happen, followed by D happening.

Other rule structures impact flow also, like this one

trigger...
branch...
- condition 1...
  - some action
condition 2...
- some action

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.

Kind regards,
Bill

Tom De Blende_eni1ol

Well, it's like this:

Custom Field is set to False

trigger (comment is made)
if conditions :
- Initiator is not X AND
- Custom Field is not set to True...
  - Set Custom Field to True
else-if condition
- Custom Field is not set to False...
  - Set Custom Field 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

trigger (comment is made)
if conditions :
- Initiator is not X AND
- Custom Field is not set to True...
  - Set Custom Field to True
else-if condition
- Initiator is X AND
- Custom Field is not set to False...
  - Set Custom Field 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

Bill Sheboy

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:

the image shows two tests on the Initiator in the first if/else block
but the text description shows one test on Initiator and one on the custom field

I wonder if there was a problem with the initial rule conditions.

Tom De Blende_eni1ol

Hi Bill,

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!

Bill Sheboy

Gotcha; is it working as you expected now?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

automation