Suggestions from Community

***

1. As organizations grow larger, it becomes increasingly impossible for Jira Administrators to own Automation business logic for every project. The recommended solution to this problem has always been (as far as I know) to delegate this to project administrators, since they do have local awareness.
2. In general, these project admins are not Automation professionals, nor do they have any real vested interest in designing rules with a minimalist design consideration. I would further assert that it is infeasible to attempt to convert them into Automation professionals, both because it would require a big time investment and because it's not really their responsibility to be.

This results in a reality where either:

• Jira administrators need to take back ownership of the entirety of Automation within their instance. This dramatically increases the size and scope of their job without any compensating feature gain, and indeed will likely create a lot of ill will from the people losing the ability to create and maintain their own business logic without going through a help desk.
• Jira administrators need to be extremely diligent in monitoring Automation rules written by non-admins as well as their usage to ensure that a poorly written rule or set of rules doesn't inadvertently blow out their allocation for the month. Failure to do so will result in NO ONE's logic running, which will likely have incredibly painful consequences for anyone attempting to use Automation for anything like critical business processes.

You could:

• Implement configurable per-project usage limits. This idea has all sorts of other not-great implications (mainly that its more about risk mitigation than actually making anything better while also forcing admins to potentially pay favorites), but it at least lets admins sleep at night knowing that a bad rule run on the first of the month isn't going to shut them down.
• Add a rule priority system. This has all of the complications introduced above but with even more of a configuration headache, but by telling Automation which rules are more important than others, we could at least ensure the most critical rules are in the least amount of danger. I think this would have to be very configurable, and allow admins to assign blocks of executions to different tiers.
• Create a class of rules which are executed more slowly but do not count towards the usage limit. There are some use-cases which call for rules which run regularly, but don't need to executed quickly. For example, take a rule which generates email to new hires a week after their hire date; it might fire at 9am, but no one is going to care if the emails don't go out until 9:30. This assumes that the root cause of this change is processing costs though, which doesn't feel like the driving force behind this.
• Customizable Utilization Notifications