You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I'm configuring a new Cloud environment and I would like to use the Automation for Jira there which is now built in the Atlassian solution. But there are some limitations for Standard plan as well as for Premium.
I decided to use Premium plan because Standard plan is limited too much. But even the Premium plan is limited by count of users per month and I'm afraid that limit 50.000 runs of multi-project rules could be problem for me.
Do anybody have some experience with a complex solution with too many rules of Automation? Did have anybody encountered a problem with limitations of the Automation?
I know that there are some other products witch can help me like Jira Misc Workflow Extensions (JMWE) or ScriptRunner but I would like to keep my solution based on clean Jira product..
I've run into some of the limitations in Jira Automation, but not the "multi-project runs per month" limit. And we have less than 50 users on the Premium plan (so a lower monthly limit). We have scores of Jira projects and 16 active multi-project or global Automation rules.
A few comments that might help you feel better:
We have two rules that trigger on "Create, Update, Transition, Move". They typically have about 2,200 executions per (rolling) 30-day period. They're both configured for our 11 most active projects. These are our "hottest" rules.
We have two other rules that run about half that. All the other rules are about 100 or far fewer executions per month.
Key points I'm trying to make: It probably won't be as bad as you think it will be. You can monitor things and adapt.
We are currently working on Jira Data Center with Jira automation, so we don't have these limitations. However, we are planning on moving to the Cloud sometime soon, and this might be a big problem for us.
One of the main problems is that when you have an automation rule that needs to be applied on a change (for example, a change of status), you can of course configure a lot of conditions that will limit the rule, but it is still counted as triggered, since the conditions are applied after the trigger and not with it. In our environment at least, many of the triggered rules are not executed since they do not comply with one of the conditions, and thus if we could have added the conditions to the trigger, they would be triggered much less.
Is there an option to do this? If not - are there any other ways of limiting the rules?
Some background: we have around 20 live projects and above 50(!) multi project automation rules that make our lives easier (both for the developers and for the people in charge of the automation)
I'm not aware of a way to "limit the rules" to avoid the concerns you're raising. They are valid concerns! But the triggers available for Automation rules trigger as configured, and subsequent conditions "narrow down" the scope of the rest of the rule actions. So there aren't any tricks to reducing the number of rule triggers (other than ensuring the triggers are configured minimally for your use-cases).
The only "trick" I'm aware of is replicating multi-project rules to be single-project rules, to avoid being counted in the "multi-project rule trigger" total.
I believe the only other option would be to upgrade your Jira Cloud plan to allow for higher automation limits.
HOWEVER, I would also say that Jira Cloud provides good metrics to keep an eye on your automation rule usage. My experience shows that its usually not as bad as we fear. Worst-case, a few rules "burn the hottest", and using known tricks on just those can keep things under control.
Who else has experience hitting Automation limits in Jira Cloud? What have you done to mitigate?
Thanks @Mykenna Cepek .
The trick of replicating the multi-project rules to single-project rules is a very problematic trick, since it forces the automation owner to manage X20 rules. Any trick to edit multiple rules at once?
Actually, yes - sort of.
You can export all your Jira Automation rules, which writes them out in JSON format. Unfortunately, it's not formatted "pretty", so I find that I need to run it through a beautifier, or read it into something (IDE, app, editor) which can reformat it for more visual clarity.
Then you can identify individual rules and edit the JSON directly. Finally, import the JSON back into Jira.
It may take some experimentation, and it's not convenient. But it should work as a "trick" that can theoretically help manage exploding a multi-project rule to be a set of single-project rules.