nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Comments

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_9zovgk

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_9zovgk

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.

Peter DelSordo

Not too often when an Atlassian Community Article will postulate 5 Problems that you are going through, and have 5 Solutions right there for you to try out. This is a good article for anyone on Cloud that has a whole lot of Automation going on! We are designing an ERP Systems Integration with our Atlassian Tool Stack for a Digital Manufacturing Firm. We are on Cloud Premium with current Automation Rule Execution limit of 550,000/month. We have hundreds (600+) of Automation Rules across ~100 Projects, so this limit is a BIG problem for us! As our Company grows, and we eventually move to the Cloud Enterprise Plan, this issue will go away for us as there are no execution limits on Cloud Enterprise for Global Automations. In our case, we are working with Atlassian Cloud Premium Support and our Atlassian Platinum Solution Partner, XALT to build out monitoring with our Datadog Platform, so we can keep an eye on rule executions and adjust queues in our MuleSoft Platform to avoid throttling. Another solution we are implementing is using AWS Lambda for some of the Automation. We can use the workaround to move some of the Multi-Project Automations to duplicate Single Project Automations. However, many of our Automations are two-way, so they have to run on Multiple Projects. It is definitely a work in progress, but the key here is we are making progress. So, there is that! {:-)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

automation