Limitations of the Jira Automation

[Ondrej Havel]

Hello,

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..

[Ravi Sagar _Sparxsys_]

Hi @Ondrej Havel 

Built in automation is great but those limitations are based on the plan and the limit on premium plan is enough for most instances, however if you think it won't suffice your requirements then ScriptRunner for Jira would be my recommendation. for building complex automations.

JMWE also is great but it is focused more on workflow enhancements.

Do you want to share a bit more about your complex automations? Are you trying to integrate with other tools and what are you concerns with using apps?

Thanks,

Ravi

[Mykenna Cepek]

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:

• It's easy to keep track of your Automation usage, and identify rules which are "burning hottest". Just click on the "Usage" tab on the main Automation configuration screen.
• Sometimes rules can be adjusted to run less often, or even combined (so they count as just 1 run, rather than 2 or 3).
• A workaround for the "multi-project" limitation is to replicate a rule to be configured for single projects. Rule maintenance takes more time, but single-project rules don't count in the monthly execution limitation. Typically this is only done for the few rules that burn hottest (if any).

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.

[Omer Meshar]

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)

[Mykenna Cepek]

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?

[Omer Meshar]

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?

[Mykenna Cepek]

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.