I don't know when conditions directly in the trigger rolled out, but I like it.

While this change appears to streamline the rule-building process, a closer examination reveals that the current implementation may not deliver the anticipated user benefits, particularly concerning resource management, audit logging, and visibility on the issue screen.

What I would want to happen:

• The automation doesn't run if trigger conditions are not met.
• The audit log has no record for "NO ACTIONS PERFORMED" because trigger conditions were not met. There is just no record, because it didn't trigger.
• The sidebar of a work item doesn't show automation that didn't run. It only shows the latest 8 rules and I don't want to see rules that shouldn't have run. I want to see rules that triggered and if they actioned or not.

My observations are as follows:

1. Automation Rule Execution and Usage: The new interface suggests that by adding conditions to the trigger, the rule will be more efficient. However, our testing indicates that the rule still "runs" and is logged as an execution attempt, even when the conditions are not met. This raises concerns about how such executions are counted against monthly usage limits. If these unfulfilled executions contribute to the limit, the perceived value of this feature as a means of reducing usage is diminished. We believe that a rule that fails its initial trigger conditions should not be considered a full execution and should not count against the usage limit.

2. Clarity of Audit Logs: The audit log, a crucial tool for debugging, records every execution attempt, including those where conditions are not met, with a "no actions were performed" message. While this logging is useful for confirming that a rule was triggered, it can also clutter the log with numerous entries for rules that failed their trigger conditions. This makes it more difficult to quickly identify successful rule executions or troubleshoot issues where a rule was expected to run but did not.

3. Visibility on the Work Item Sidebar: The "Automation" section in the sidebar on a work item is a vital source of information for our team. Currently, it only displays the most recent automation runs, limited to the last 8 entries. When an automation rule runs but the trigger condition stops it, it still consumes one of these valuable spots. This can hide relevant successful automations or other important activity, making it harder for our users to quickly understand what has happened to an issue.

In summary, while the new user interface is a positive step toward logical rule construction, the current backend behavior diminishes its practical value. The lack of a clear distinction between a failed condition and a successful action in terms of usage, audit logging, and on-screen visibility can lead to confusion and inefficiency.

We recommend that you consider the following enhancements:

• Clarify usage counting: Provide clear documentation on whether rule executions that fail conditions count toward monthly limits. Optimally, these should not.

• Improve audit log filtering: Offer an option to filter the audit log to show only successful rule executions or to group failed attempts.

• Enhance sidebar visibility: Refine the logic for displaying automation runs on the work item sidebar to prioritize successful actions over failed attempts, perhaps by only displaying rules that performed an action.

Thank you for your time and attention to this matter. We are committed to optimizing our use of Jira and believe these improvements would significantly enhance the user experience for all administrators and end-users.