Rules configured with the Jira automation rely on events (such as issue created, issue updated, or new comments added) to be triggered. When rules are working correctly, they should listen to the events configured with, and add a new entry to their audit logs, regardless of whether an action was executed. However, sometimes, automation rules might "miss" or "skip" some events.

This article lists the most common reasons why a rule wasn't triggered as expected and how to identify them.

このページの内容

• "ルールがトリガーされない" とは
• Environment requirements
• Identifying error's root cause
• 原因
  • Root cause 1: Rule is disabled
  • Root cause 2: Allow rule trigger option is disabled
  • Root cause 3: Jira automation is disabled on one node in the Jira Data Center cluster
  • Root cause 4: Jira automation threads aren't running on one node in the Jira Data Center cluster
  • Root cause 5: Rule should be triggered on the ISSUE CREATE event, but the wrong event is fired in the workflow
  • Root cause 6: Rule should be triggered on the ISSUE CREATED event, and the issue was created from a CSV import
  • Root cause 7: All Jira automation execution threads are stuck due to a third-party app
  • Root cause 8: Rules configured with the "Field value changed" trigger aren't triggered due to the "Field Security Plugin for Jira" app
  • Root cause 9: Rules configured with the "Multiple issue events" trigger aren't triggered if the event was published by another rule
  • Root cause 10: Multiple rules are triggered by the same event and one of these rules is taking more than 5 minutes to complete
  • Root cause 11: The rule is configured using the trigger "Multiple issue events" and the wrong event was selected
  • Root cause 12: The rule is configured using the trigger "SLA threshold breached"

"ルールがトリガーされない" とは

First, let's clarify what "a rule isn't triggered" means in the context of Jira automation:

• Let's assume that we have a Jira automation rule configured to be triggered when new issues are created
• Let's assume two issues were created after the rule was configured, with keys SCRUM-73 and SCRUM-74. When checking the rule audit logs, if no entry is showing at all for an issue (issue key SCRUM-73 in the example below), then it means that the rule didn't get triggered for this issue:
  
  
  

If you expected an automation rule to be triggered upon a particular event, but no entry was recorded in the audit logs, then one of the root causes listed below might help you.

Environment requirements

Starting from Jira Data Center 10.0, we integrated Jira automation (formerly Jira automation) as part of Jira Data Center (both Software and Service Management), offering you the convenience of upgrading either through Jira or the Universal Plugin Manager (UPM). To streamline and enhance your experience with Jira automation, we've decided to solely offer it as a bundled version starting from Jira 10.0.

This guide assumes that you're using:

• Jira Data Center 8.0.0 or later
• Jira automation Data Center 7.4.0 or later

Identifying error's root cause

To identify which root cause is relevant:

1. Ensure the automation rule that wasn't triggered is enabled. If it's disabled as shown in the screenshot below, go to Root cause 1: Rule is disabled.
   
2. On the Rule details page, check the Allow rule trigger setting. If you see that the automation rule only occasionally doesn't trigger, and if the events that are missed were caused by other automation rules, check out Root cause 2: Allow rule trigger option is disabled.
3. Check the type of trigger the impacted rule is using:
   • If the rule is using the Issue Created trigger:
     • If the rule isn't triggered by issues created in a specific project or with a specific issue type, go to Root cause 5.
     • If the rule isn't triggered by issues imported from a CSV file, go to Root cause 6.
   • If the rule is using the Field Value Changed trigger, then Root cause 8 might be relevant.
   • If the rule is using the Multiple Issue Events trigger, then Root cause 9 or Root cause 11 might be helpful.
   • If the rule is using the SLA Threshold Breached trigger, go to Root cause 12.
4. Check the Audit logs for an example of an affected automation rule. If the automation rule is often triggered but intermittently skips some issues (as shown in the example below), then Root cause 3 or Root cause 4 might be relevant.
   
5. Check if Jira automation is enabled in the Jira application: go to Settings  > Manage Apps > Manage Apps. 
   • In the case of a cluster of nodes in Jira Data Center, it's important that you confirm that Jira automation is enabled on each Jira node since we've seen situations where it might be disabled on a specific node. If Jira automation is disabled on at least one node, go to Root cause 3.
   • To check the state of Jira automation:
     • Log directly into each node (by bypassing the Load Balancer) and go to Settings  > Manage Apps > Manage Apps.

     • Or generate a support zip from each node and search for Jira automation in the application.xml file. If Jira automation is disabled on a node, you'll see something like this:

           <plugin>
             <key>com.codebarrel.addons.automation</key>
             <name>Jira automation</name>
             <version>8.0.0</version>
             <vendor>Atlassian</vendor>
             <status>DISABLED</status>
             <vendor-url>https://atlassian.com/</vendor-url>
             <framework-version>2</framework-version>
             <bundled>User installed</bundled>
           </plugin>

6. If Jira automation is enabled on all the nodes of the Jira Clusters, but automation rules are randomly skipping some issues, then the next steps is to generate thread dumps and search for the automation threads. If you see that most Jira automation threads are missing in the thread dumps on at least one node, then this node is "not healthy" and Root cause 4 is relevant:
   
   
   
   • 単に比較する際は、Jira ノードが健全であれば、次のスレッドが見つかるはずです。
     
7. When analyzing the thread dumps, if you find that all the Jira automation threads automation-rule-executor:thread-X are in the BLOCKED state (as shown in the example below) or in the TIMED_WAITING state, then Root cause 7 might be relevant:
   
   

原因

Root cause 1: Rule is disabled

If a rule is disabled, it'll stop listening to the event it was configured with, and it'll no longer be triggered.

Root cause 2: Allow rule trigger option is disabled

初期設定では、新しいルールの [ルール トリガーを許可] オプションが無効になっています。このような場合、ルールがリスニングしているイベントが別の自動化ルールの結果として発生すると、このルールはそのイベントを無視します。

To allow other automation rules to trigger this rule, in the Rule details, select Allow rule trigger.

You can find more information about this scenario and its resolution in the following article: Jira automation: Rules don't get triggered if the trigger came from another rule.

Root cause 3: Jira automation is disabled on one node in the Jira Data Center cluster

If you're using a cluster of Jira nodes in a Data Center environment, and if a node didn't startup properly, Jira automation might be disabled on that specific node.

この場合、次のようになります。

• whenever an issue is created or updated on that node, the event fired by this issue will be ignored by Jira automation since it's disabled on that node.
• the common symptom is that automation rules are triggered for most issues, but they're also skipping issues.

You can find more information about this scenario and its resolution in the following article: Jira automation: Rules aren't triggered for some Jira issues due the application being disabled.

Root cause 4: Jira automation threads aren't running on one node in the Jira Data Center cluster

If you're using a cluster of Jira nodes in a Data Center environment, there might be a situation where Jira automation is enabled on all the nodes, but for some reason it failed to initialize its own threads during the startup. The reason why Jira automation might fail to initiliaze its thread is unclear, but it might happen as a rare corner case.

この場合、次のようになります。

• whenever an issue is created or updated on that node, the event fired by this issue will be ignored by Jira automation since it's disabled on that node.
• the common symptom is that automation rules are triggered for most issues, but they're also skipping issues.

You can find more information about this scenario and its resolution in the following article: Jira automation: Rules aren't triggered for some Jira issues due to missing threads.

Root cause 5: Rule should be triggered on the ISSUE CREATE event, but the wrong event is fired in the workflow

Rules that are triggered when new issues are created rely on the "issue created" event to be fired by the Jira application. By default, any workflow is configured to fire the "issue created" event using the issue creation, so that any functionality that relies on this event (such as Jira notifications or automation rules) can be triggered.

ワークフローの作成トランジションの事後操作が別のタイプのイベントを発生させるように編集された場合、このイベントに依存する自動化ルールはトリガーされなくなります。

ワークフローが課題作成時に正しいイベントを発生させているかどうかを確認する方法は次のとおりです。

1. Go to the workflow associated to the type of the created issue for which you expected the rule to be triggered.
2. Select Create transition and then the post functions link.
3. Check the event that is fired in the post functions, and verify that it's either:
   • Firing the event of ID 1 (which is the "issue created" event).
     
   • Or explicitly firing the "issue created" event.
     

Root cause 6: Rule should be triggered on the ISSUE CREATED event, and the issue was created from a CSV import

Jira comes out-of-the-box with two types of CSV import:

1. Bulk Create, that you can access in Issues > Import issues from CSV.
2. CSV External System Import, that you can access in Settings  > System > External system import > CSV.

While the first type of import is available to users who are granted the Create Issues project permission and the Bulk Change global permission for the project, the second type of import is only available to Jira System Admin users.

Something that is important to note is that the 2nd type of import doesn't trigger the Issue Created event when issues are created via this import. As a result, any Jira (or third-party app) functionality that rely on this event to be triggered will not be triggered. Such functionalities include:

• Jira のネイティブ Webhook
• Jira automation's "Issue Created" Trigger
• 「課題の作成」イベントに基づくメール通知

This behavior is tracked in the feature request Issue Created or Issue Updated events aren't trapped when importing issues using CSV External System Import.

If the automation rule that didn't get triggered is configured with the "Issue Created" event, and if the issues were created using the CSV External System Import, then the behavior is expected and this root cause is relevant. Instead, use the Bulk Create CSV import  to ensure that the rule will be triggered for the imported issue.

Root cause 7: All Jira automation execution threads are stuck due to a third-party app

The Jira automation execution threads automation-rule-executor:thread-X are responsible to process events that are accumulating in the Jira automation queue. We've seen a situation where all these threads might get into a "BLOCKED" or "TIMED_WAITING" state and stop running because of a third-party app.

To check if this root cause might be relevant, go to Jira automation: The automation executor threads are stuck because of the usage of a third-party app.

Root cause 8: Rules configured with the "Field value changed" trigger aren't triggered due to the "Field Security Plugin for Jira" app

 The third-party app Field Security Plugin for Jira might prevent automation rules using the Field value changed trigger from being triggered when the field they're monitoring is updated. To check if this root cause is relevant, go to Jira automation: Some automation rules using the "Field value changed" trigger aren't triggered.

Root cause 9: Rules configured with the "Multiple issue events" trigger aren't triggered if the event was published by another rule

To verify if this root cause is relevant, check the following points:

• The only type of impacted rules are the ones configured with the Multiple issue events trigger.
• The impacted rules are already configured with the Allow Trigger option ticked (allowing other rules to trigger these rules).
• The events that these rules should be triggered from are published by other automation rules.
• The rules that are publishing the event do not have the checkbox Publish newer style 'IssueEventBundle' select in the Publish Event action.

If all the points above are verified, then this root cause is relevant, and we are facing the bug JIRAAUTOSERVER-910 - Getting issue details... STATUS .

To fix this issue, select Publish newer style 'IssueEventBundle' Publish Event action of all the rules that are publishing the events.

Root cause 10: Multiple rules are triggered by the same event and one of these rules is taking more than 5 minutes to complete

In the case where multiple rules are triggered by the same event, Jira automation loops over each rule (rule by rule) to process this event. If one of the rule that is processing the event takes more than 5 min to complete, the following happens:

• The event gets cleared from the cache (because Jira automation automatically clears events from the cache that have not been access for more than 5 min).

• The exception below is thrown in the Jira logs:

  2023-11-07 09:59:18,905+0100 automation-rule-executor:thread-3 ERROR some_user     [c.c.j.p.a.service.execution.JiraThreadLocalExecutor] Unexpected error in thread local executor with actorKey 'some_user'.
  java.lang.IllegalStateException: There is no execution wih id=TenantExecution{tenantExecution=TenantExecution{tenantContext=TenantContext{environment=prod, clientKey='com.codebarrel.tenant.global', tenantId=TenantId{id='00000000-0000-0000-0000-000000bbbbbb'}}, executionUuid='c463420f-d3ae-41cb-9f4c-7d0122769999'}, auditItemId='10360381'}
  	at com.codebarrel.automation.api.execution.DefaultExecutionFinishSynchronizer.lambda$gerRuleInfo$2(DefaultExecutionFinishSynchronizer.java:108)

• Jira automation exits the loop even though there were still some rules left to process the event
• Ultimately, some rules miss the event and don't get triggered

This behavior was identified as a bug and reported in JIRAAUTOSERVER-946 - Getting issue details... STATUS

To verify if this this root cause is relevant:

• Check if the event that was missed by some automation rules was processed by at least another automation rule that took more than 5 minures to complete (automation rule execution times can be seen in the "Duration" column of the audit logs)
• Check if you can find the exception mentioned above in the Jira application logs

There is unfortunately no easy workaround for this bug, other than doing the following:

1. Identify which rule is taking more than 5 minutes to process the event that was missed by other rules.
2. Then, either disable this rule or optimize it so that it takes less than 5 minutes to complete.

Root cause 11: The rule is configured using the trigger "Multiple issue events" and the wrong event was selected

If a rule is configured with the trigger Multiple issue events, it's important to select the right event that this rule should be triggered on. For example, if this rule is configured to react to the event "Issue Updated", and you expect the rule to be trigger when an issue is transition to a new status, then the event figured by that transition needs to be the same event the rule is configured with.

To check if this root cause is relevant:

1. Go to the Rule configuration and check which event is configured with the trigger Multiple issue events.
2. Go to the workflow used by the Jira issue that failed to trigger this rule, check the transition that was used for this Jira issue, and look at the list of post-function configured with this transition.
3. Look at the event that is fired by this transition.
4. If the event fired by the transition doesn't match the event the rule is listening, then this root cause is relevant.
5. In such case, either edit the workflow transition or the automation rule trigger so that both events match.

Root cause 12: The rule is configured using the trigger "SLA threshold breached"

If the rule is configured with the trigger SLA threshold breached, the rule may not be triggered if the SLA of Jira Service Management request stops exactly at end of a working day.

This behavior was reported as a bug in https://jira.atlassian.com/browse/JIRAAUTOSERVER-188, and was fixed in Jira Software and Jira Service Management 10.1.0.