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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.