Does Automation billing policy seem completely insane?

[Benjamin Peikes]

***Venting***

So we just found out that Global Automation rules and multiple project Automation rules have caps in terms of the number of executions you can have. Automation rules on single projects are not capped though.

This is the most ridiculous billing practice. To get around the caps, we have to make copies of our rules for each project. We had started moving away from ScriptRunner, but now we are running into these capping issues.

How have people dealt with this? Especially if you set up with a project per client. Did Automation always have these caps?

[Esther Strom]

Hi, @Benjamin Peikes - I understand how frustrating this is. We are on Premium (not just for automation), but before we switched we had to do quite a bit of work keeping up with rule maintenance in many projects. As far as I'm aware this has always been the case; the caps are not new (at least, not since Atlassian integrated what used to be a third-party plugin as native functionality.)

It can be a pain, but if you're talking about a separate project per external client, I'd honestly keep all of my rules separate anyway, as it's too easy to accidentally trigger something in multiple projects that really should be limited to one (i.e. copying data from one to another, which might allow users to view info they shouldn't be able to see if your projects are locked down accesswise.)

[Jack Brickey]

another useful article - what-are-service-limits 

[Jack Brickey]

Hi @Benjamin Peikes , indeed there are limitations. Here is some info on this explore-jira-cloud-plans - reference the bit on Automation. Personally, as I am on Standard I work almost entirely on project automation. To date copying a rule hasn't been an issue for me.