Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Rule trigger another rule error

Jan Nolens
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
June 29, 2025

I'm using Jira cloud and have 2 projects with some linked work items.

Both projects have the same settings with the same permissions.

 

I have an automation rule to synchronize status between 2 linked work items, which works as intended.

image.png

 

In one of the projects, I have another automation rule which can trigger a status change on its work items. I do want the linked work items to be synchronized, so I checked the tick box to allow automation rules to trigger the status change synch rule to work.

Now I have an issue that the synchronization of the linked work item, triggers this same rule on the linked item as well. This would result in an infinite loop if it wasn't for an error because automation cannot transition to the status it already has (thank you workflow restriction).

To avoid this resynch, I tried to add an if statement in the branch, but for some reason the automation will always pass on that if statement and try to update the status for a 2nd time.

image.png

 

 

First of all: I thought rules should not be able to trigger themselves so why does the status change of the first run through the rule, trigger itself again? Is this because it is being triggered on a different work item?

2nd: why does my if statement not stop the 2nd run through the rule and still attempt to transition again?

2 answers

1 accepted

0 votes
Answer accepted
Dick
Community Champion
July 2, 2025

Dag @Jan Nolens 

In your automation, you have a non-descript trigger followed by a branch that is allowed to change the status for both “is duplicate” and “duplicates” conditions. That in itself generates the infinite loop if the automation is allowed to start itself.

How to avoid this from happening?
You should construct two automations, nearly identical, yet each with its own singular branch: so one for “is duplicate”, and the other for “duplicates”.
Only one of these automations should be set to be able to be triggered by other automations.

This means that you should choose which of the branches should override the other, the automation with the overridable branch should be set to “can be triggered by other automations”

Kind regards,
Dick

Jan Nolens
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 2, 2025

Dag @Dick

That could indeed work to avoid the infinite loop.
My automation trigger is 1 directional, however I would need to make sure the duplicate link is always in the same direction as well.

This definitely something I should look into.


Dick
Community Champion
July 2, 2025

Hi @Jan Nolens , remember that execution of branches is done in parallel by Jira’s automation engine. There’s no way of telling the order in which they are executed nor finish. The limbo state resulting can in some cases be avoided by either separating them from each other, or by using a re-fetch of the current work item. As you’re dealing with multiple work items, I went for the former solution.

Kind regards,
Dick

0 votes
Trudy Claspill
Community Champion
June 29, 2025

Hello @Jan Nolens 

Welcome to the Atlassian community.

Addressing your "first of all", if you check the box to allow a rule to be triggered by action taken by another rule, then it can be triggered by the actions of any rule. So the action of rule A can trigger rule A. This is an intentional feature to support recursive rule execution.

Regarding why the IF statement doesn't work as expected:

1. Please provide screen images showing the results in the rule execution Audit Log.

2. Add Log Actions to your rule to log the value of the Status of the linked issue and the trigger issue immediately before the IF statement. That will help validate what values are being compared in the IF condition.

Jan Nolens
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
June 30, 2025

Thank you for the reply.

It seems the IF statement I used is not behaving as I thought it would.
I had added a smart value if statement and that one seems to trigger correctly

image.png

It would probably be helpful to understand why these 2 if statements are not the same, however I can work with this

Trudy Claspill
Community Champion
June 30, 2025

Hello @Jan Nolens 

Can you provide a screen image showing the details of the "Status does not equal" component?

Can you add the Log actions that I recommended, placing them before the "Status does not equal" component, run the rule again, and share screen images showing all the details from the Audit Log for execution of the rule?

What are the project Types of the projects in scope for this rule? Get that information from the View All Projects page under the Projects menu.

Can you check to see if there is a Global custom field named Status? There should not be, but if there is that could confuse the Automation Rule.

Jan Nolens
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
June 30, 2025

Both projects involved are company managed software projects and they share the same configurations: issue types, schemes, workflows, fields....

 

Log when status field on both work items are different: 

image.png

 

Log when both items are the same (runs automatically again because last action of previous run, makes it run again)

image.png

 

 

Config of the work item field condition check which passes in both runs above

image.png

 

Automation rule:


image.png



Trudy Claspill
Community Champion
June 30, 2025

Thank you for that additional information.

Would you consider doing another test removing the smart value compare to see what is reported?

As it stands now the work Items Field condition and the Smart value condition are getting the same results. I would like to see if removing the smart value condition will result in the problem occuring again. If it does then I would suspect a timing issue where the rule is running before the data is truly saved in the database.

Jan Nolens
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
June 30, 2025

in the case where the status values are different, both conditions show a different result.

The work item field condition shows it passes, the smart values condition says it does not pass...

image.png

If I remove the smart value comparison I will get an error because the next step is to transition the card which it cant do as the workflow does not allow transition to the same status value.

image.png

Trudy Claspill
Community Champion
June 30, 2025

Thank you for that additional information.

I have recreated the scenario in my own environment and am seeing the same results that you see.

I happen to be using a Free Jira Cloud subscription. What type of subscription are you using?

I'm asking other community members to take a look at this.

Jan Nolens
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 1, 2025

We have a company license. Don't know the details of it myself.

Trudy Claspill
Community Champion
July 2, 2025

Let me see if I can sum up this scenario.

1. There is an Automation rule that executes issues transitions.

2. There is a second Automation rule that reacts to issue transitions
- This rule needs to react to both manual transitions and transitions executed by other automation rules.
- This rule needs to react to all transitions (for issues in the specified project scope), not just transitions to or from a subset of statuses.
- This rule will set the status of issues linked to the rule trigger issue to the status of the rule trigger issue.
- This rule should execute that synchronization only if the linked issue and rule trigger issue are not already set to the same status

3. Because the second rule has to react to transitions made by other automation rules it needs to have the option enabled to be triggered by Automation rules.

4. Because of #3, the transition being executed within the second rule causes the second rule to be triggered again.

 

And the observed behaviour is:

When #4 occurs (the second rule is triggered again by the transition that it executes) the Work Items Field Condition used within the branch to compare the Status of the linked issue to the Status of the Trigger issue is not detecting that the Statuses are the same. But the Advanced Compare condition does detect that the statuses are the same.

 

We know that the rule will work as intended when the Advanced Compare is used.

 

So the question is:

Why does the Work Items Field Condition get a different result than the Advanced Compare in this scenario?

 

Have I summed it up correctly?

Jan Nolens
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 2, 2025

That sounds right to me.

Yes, I can use the advanced compare so that's fine... But the fact the work item field compare is not behaving as expected makes me think I misunderstand it's functionality...

Trudy Claspill
Community Champion
July 2, 2025

I don't think you have misunderstood the functionality. I would expect it to be able to tell that the values were the same, in this scenario.

There could be some weird timing issue with the rule calling itself for the same pair of issue it was just operating on.

One other thing I can think of to try is to add a Re-fetch Issue Data action right after the trigger, and one right as the first thing within the Branch.

One last thing I can think of to check would be the Post Functions for the workflow transition(s). Maybe there is something odd about the Post Functions that would become evident if we knew what they were.

Dick
Community Champion
July 2, 2025

This would be true only after a re-fetch… 

Trudy Claspill
Community Champion
July 2, 2025

What are you referring to when you say "this"?

Dick
Community Champion
July 3, 2025

@Trudy Claspill Fields of a modified work item display only the modified content correctly after a re-fetch. The action of modifying a field’s value is done in the database, not the work item “copy” that is used inside the automation. The modified field value needs to be re-fetched to work with it.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events