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; } } }

Event processing chain

Marcus Toepper

Hi community!

I am currently doing a bunch of automations, basically trying to ensure some automated reactions for DoDs and such. Now, I've run into some problems I can't figure out. I've broken things down to the first step I don't get.

I am dividing different functionalities in different automations in order to avoid cluttered big ones. Now it seems, I cannot ensure execution in a specific order. E.g. adding a checklist, checking a checklist and moving to a different state. They seem to be executed in an arbitray order. So, my thought was, using a label that I would set in one automation and remove in the next at the end of the execution.

So, my first automation actually adds a certain label. I currently trigger that one manually. In the ticket view itself, the newly added label appears instantly. In the log and mails etc. however, it doesnt. Even a second function that responds to changes is not called. Some seconds later however, the new label appears in the logs when called again.

Question: Is Jira just not build for that kind of event processing or (much more probable) do I just don't get how it should be done?

Any hints would be greatly appreciated!

Best regards,
Marcus

Accepted answers

Jack Brickey

Hi @Marcus Toepper , I have done something similar in the past successfully by including delays and refetch data. It is hard to say what might be going on without seeing your rules. Something like the following example should work.

rule 1 - add label1
rule 2 - trigger on issue updated, delay 3s, refetch data, check if label1, remove label1, do stuff, add label2
rule 3 - trigger on issue updated, delay 3s, refetch data, check if label2, remove label2, do stuff, add label3
etc

i hope the above makes sense

All comments

Jack Brickey

rule 1 - add label1
rule 2 - trigger on issue updated, delay 3s, refetch data, check if label1, remove label1, do stuff, add label2
rule 3 - trigger on issue updated, delay 3s, refetch data, check if label2, remove label2, do stuff, add label3
etc

i hope the above makes sense

Marcus Toepper

Hi Jack!

Thanks for the reply, much appreciated. How do you get the delay in the automation?

Besr regards,

Marcus

Bill Sheboy

Hi @Marcus Toepper -- Welcome to the Atlassian Community!

Without first seeing any of your rules and their audit log details and knowing your Jira version...

Although it is possible to sequentially run a set of automation rules, that solution approach can be brittle for several reasons...

First thing, when rule #1 performs actions which you want to trigger rule #2, the option to "Check to allow other rule actions to trigger this rule..." must be enabled in the details at the top of rule #2 (i.e., the downstream rule of your process). If not enabled, the automation engine automagically prevents this to avoid accidental rule looping.

Please consider when this option is enabled, *all rules causing the event in the same scope* could trigger it, including recursively triggering the rule itself. This can lead to errors and runway execution, until the rules halt due to the service limits. Please use caution, test, and thoroughly document your rules to help manage the risks.

Next, timing is important for automation rules, and there are known racetrack timing problems with some rule triggers and components. That is, the rule can start before all of the work item data is available for the rule to use. Again, without seeing your specific rules, one mitigation is to add the Re-fetch Work Item Data action immediately after the trigger and before any other steps. This will slow the rule slightly, reloading the data before the rule proceeds.

And if you are using Jira Cloud, this timing problem also causes challenges for the new feature to add conditions to triggers directly. I recommend not using that feature yet; instead, add separate conditions after the re-fetch action. Atlassian is aware of this timing problem, and as of July 2025, is working on architectural changes to address it.

A related, and different, behavior to note is when a rule updates a trigger work item, that data is not yet available to the rule. Specifically, it is updated in the cloud storage but not in what the rule has stored in memory. Again, the re-fetch action may be used to reload the data, making it available to the rule's processing. To learn more about such data visibility, please see this article I wrote.

Next, when Atlassian has an outage impacting rule execution, there is no documentation of exactly which events / triggers will eventually lead to rules running to "catch up" after the outage. What this means is a finely-tuned chain of multiple rules could halt processing part way through the chain and never complete. Atlassian recently added automatic retry capability for short interruptions to already running rules, but my understanding is that does not handle an in-progress outage for rules that have not started, or a larger scale outage. To learn more about this new retry, please see this Atlassian article.

All that to say: when you have a chained-rule solution, preemptively perform fault analysis to understand how you could "fix" any problems if the chain fails to complete, or completes in error. For example, using a Scheduled Trigger rule with JQL to find / fix work items.

Finally, when one believes a chain of multiple rules are needed, consider if instead the approach can be redesigned with fewer rules, performing the steps sequentially in a single rule, to reduce the risks.

Kind regards,
Bill

Marcus Toepper

Hey everyone!

Thanx for your support, I got it now. Seems the dumb side of stuff was me forgetting to enable the triggering, the other part was our system that actually seems to be pretty slow. Long story short: Works now, Thank you so much!

Just out of curiosity: If I forget either the check or the removal of the label, I have an infinite loop. Is there any way to supress this?

Best regrads,
Marcus

Bill Sheboy

Hi @Marcus Toepper

Without seeing your actual rules and the audit logs, diagnosing any looping is difficult. You may just be missing a conditional check after a rule triggers to prevent it from further processing. If you post your rules and logs, the community can offer better suggestions.

Bill Sheboy

Hi @Marcus Toepper

Just following up to check if this answered your question. If so, please consider marking this one as "answered". That will help others with a similar need find solutions faster. If not, please let the community know what help you need with the rule changes.

Thanks!

Welcome!

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

Quick Links

Find more posts tagged with

automation