📣 Improvements to Manual Triggers in Jira Cloud Automation, Configure Filters For Issues

[#1]

Hello, Community 👋 Scott from Automation Platform here.

We are excited to announce today some improvements to Automation in the form of being able to apply filters to Manual Trigger rules.

With this feature, administrators now have the ability to manage the visibility of manual rules for different types of issue fields. For instance, if a manual rule is specific to the epic issue type, a filter can be set up and applied to the rules, ensuring they are not displayed for other issue types like stories or tasks.

In the board view, when multiple issues are selected, the list of manual rules loaded on the lightning menu will be filtered on all selected issues.

What will it look like for Automation admins?

We’ve started off small with what filters are available while we assess performance impacts; admins can create display filters based on the following:

• Issue Status

• Issue Type

• Issue Assignee

This release will enable admins to apply a single filter to a manual rule. We will examine usage and performance to assess additional potential filter types in the future.

Issue Status

Admins have the ability to create a filter based on the status of an issue. All statuses that are available in a project can be used for filtering. Admins can select one or multiple statuses to create a filter.

Issue Type

Admins have the ability to create a filter based on the issue types. Any issue type within a project can be utilised for filtering. Admins can choose one or multiple issue types to create a filter.

Issue assigned

Admins have the ability to create a filter based on an assignee. All members of a project are available to be filtered on. Admins can choose one or more assignees to create a filter.

What will it look like for Automation users?

Automation users are unable to view or create filters on their own. However, they will have a reduced number of rules displayed in the lightning and actions menu, which is determined by the configured and applied filters.

The benefits of applying filters can reduce the risk of running manual rules against the incorrect issue type, eliminating the possibility of a user accidentally running a manual rule that they shouldn't, and reducing the overall number of rules in the list, as well as minimizing clutter by displaying only the relevant rules for a given situation.

When will filters be available?

The new filters are now available in Jira Software, Jira Work Management, and Jira Service Management wherever issues are accessible.

We want to hear from you!

We appreciate feedback from the community regarding how these filters work for you and any suggestions for future iterations. If you have any questions or would like to share your thoughts, please leave a comment below, schedule a call with us, or provide feedback directly from within Automation.

[Andrey Kiyanovsky]

Thanks for the improvements here. Can you please implement Jira custom fields on the automation forms and smart values as predefined values?

[Tomislav Tobijas]

Yay! Nice addition to this automation trigger 🎉

First look feedback - it would be perfect if you could combine multiple filters. For example, we now use one post function that triggers the automation rule which then performs actions. Basically, for one of our use cases, we would require to have a manual trigger only in specific status for one issue type (to be precise, for one request type).

[Boldizsár Vermes]

This is a powerful addition!

What I'm still missing (or just haven't been able to figure out how to achieve) is to narrow the scope of people who have access to a manually triggered rule to roles instead of groups. I am working with project scope rules and want to give access only to project admins for certain rules.

[Haddon Fisher]

This is a great first step towards being able to to hide the lightning button and action menus entirely...any idea when that's coming? At the very least restrict it to project roles as Boldizsár Vermes mentioned so we can limit it to admins in 99% of projects.

While it's definitely a rare occurrence, we do have times when we need a rule with a manual trigger. Hardcoding a giant dropdown right next to the "Status" button seems like a disproportionately obtrusive and large solution for such a small problem though.

The custom field UX pattern seems like a much better fit here i.e. let us make "buttons" which then can be controlled via the "Layouts" and appear in any place like a custom field.