Hi,

In our case, we currently have Jira under the 1.800 tier. However, we have noticed that the gap between the premium and standard plans is quite significant. While we use less than 100K, the premium plan offers a 1.8 million limit, which far exceeds our requirements and doesn’t quite align with our actual usage.

We would sincerely appreciate your consideration of either increasing the limit for the standard plan or offering an option to extend the limit specifically for standard users, as this would better suit our needs.

Thank you

Hi Atlassian Team,

Please consider, in our case we have Jira in tier 1.800. imagine.

The gap between the premium and standard plans would be very very large. We use less than 100K, but the premium option provides a 1.8 million limit, which doesn’t align with our needs.

We would greatly appreciate it if the limit for the standard plan could be increased, or if there were an option to extend the limit for the standard plan. Please. 

Hi,

For my customer, Standard plane is great, but they need more times to run automation per month.

Thanks.

Certain organizations may have a very lean team which benefits from a higher amount of automations. This should be seen as a selling point of Jira to allow leaner teams to achieve higher productivity through automation. Locking the potential for organizations to benefit from automations behind the premium subscription does not make sense because it does not allow usage to scale according to business needs and is a commercial design that drives customers away from this wonderful platform. If i have 100 users requiring 2000 automation runs per month, it does not make sense for me to upgrade to premium for 100,000 automation runs.

Hi,

Would appreciate there being a different billing model for automation processes specially for customers who don't require the use of "premium features".

This is rather frustrating as this was the way our system was initially developed and now we are basically "forced" to going premium and we operated efficiently without any "premium feature".

I suggest there be different automation levels so as to give the customer options and adjust the development needs.

Since single-project automations start to count towards the global, there should be a separate licence for automations.
It doesn't make sense for a company to have to upgrade to premium just to have more automations.
I run 13k automations a month, many of which were single-project automations, and now I have a limit of 5k automations and I have teams stopped because the process isn't working as expected.

Okay. Either those things, or your automation executions run out. What's worse?

To those thinking about using scheduled rather than event-driven triggers for rules, please consider such rules could run into additional challenges:

• One obvious one is delayed value of automation, as changes by users that would have triggered event-driven rules in a timely manner will be delayed, possibly leading to user errors and unnecessary load on Jira admins explaining "why" something is happening
• Scheduled triggers, branches, lookups, etc. have a maximum limit of issues / things they will handle.  And when expecting more, the rule schedule would need to be set more frequently and the rule written to exclude previously processed issues to mitigate that volume.
• All rules have processing time and looping limits; when using a lot of scheduled rules that process many issues / things those limits could be encountered.  (This particularly can occur with a rule error, leading to a run-away situation.)

Please look here to learn more about the other service limits (beyond usage limits):

https://support.atlassian.com/cloud-automation/docs/automation-service-limits/

What they're essentially directing, in my view, is that automations should be scheduled rather than triggered by individual events. If you schedule an automation that looks back, let's say on a 15 or 30 minute frequency, then it makes no difference how many users you have. It will deal with, in theory, an infinite number of requests.

What is 100% ridiculous is that our 1000 user installation gets a many runs as a 20 user installation!