-
Suggestion
-
Resolution: Unresolved
-
0
-
Suggested improvements:
- Ability to get notification that restrictions for automation rule have been lifted - Currently there is automation limit for Daily processing time (60 min per 12 hrs) and not possible to send notification that restrictions for automation rule have been lifted.
- Email Notifications for Item Queued Globally Limit - As per the Service Limits Documentation - https://support.atlassian.com/cloud-automation/docs/automation-service-limits/ , only Notifications are supported for the event type "Daily Processing Time (60 min per 12 hours). Please enable Notifications support for Issues Queued Globally (50,000) and other events considering the importance of Monitoring & Performance reasons.
- As per this. - https://support.atlassian.com/jira-software-cloud/docs/what-are-service-limits/. Daily processing time is 60 min per 12 hrs one which tasks to get queued up and resulting in slowness. Improving this time would allow users to have a better experience while using A4J
- Since there's a limit of 65 components by rule in a way to make sure the rules will run stably and won't time out, it would be good if when accessing the rules the amount of components the user might see how many components the rule already has
***
Do not deprecate Workflow Triggers or allow automation plans to increase automation limits -
I hope this is the correct place for this. As discussed here: https://community.atlassian.com/t5/Jira-Software-questions/When-are-the-workflow-triggers-for-branches-going-to-deprecate/qaq-p/1611693 , there is concern in the community around the deprecation of workflow triggers. Many of us are already hitting our automation limits monthly, and without the ability to simply purchase plans to increase automation limits, we're asked to double our Jira subscription costs.
While I understand that we can set rules for individual projects, this just isn't feasible when I have 100s of projects on a small team or 1000s for larger teams. One thing changes in that workflow and you're asking us to update 1000 individual rules.
Please reconsider the current published solutions and offer better options for your users.
- is duplicated by
-
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed
[AUTO-44] Make it easier to work within Automation Service Limits, e.g. increase Daily processing time and Hourly processing time, option to reset/increase limits, show how many components a rule has, option to manage notifications of % service limit reached
Not sure if its already present, but having a page for all the limits would be great. Something similar to AWS Quota, for all these
https://support.atlassian.com/cloud-automation/docs/automation-service-limits/
Some things like component limits could be shown in the Automation Rule itself.
With the aggressive count of automation rules/usage, we've surpassed the 5000 Jira automation rules within 3 days due to the necessity of attaching a form to a ticket submitted via the RESTful API. Currently, the workaround involves manual monitoring of rule limits and reaching out to Jira for resets when needed. This process is cumbersome, especially considering that we're just attaching a form to a ticket—a functionality readily available when creating a ticket from the portal. It would greatly enhance efficiency if we could manually set and increase these limits, given that this is a workaround for a core missing feature in Jira Service Desk.
I've just hit the 65 components limit. Seriously? This just reinforces my view the native Jira automation is only designed for small number of very simple automations and isn't suitable for Enterprise solutions. My single-function automation is not that complicated but splitting it will be. I'm not going to waste time on splitting the automation - I'm going to order Scriptrunner.
I agree with 714d15410c50' post.
Definitely need more than 65 components. Based on how components are broken down, it's very limiting, especially when you want "IF/ELSE/(CASE)" type logic.
If you're exceeding these limits, consider migrating to a Forge app instead. About Forge (atlassian.com) You'll find a Forge app much easier to maintain in the long run than a 100 component automation rule. Forge Apps also instantly trigger on issue events, and have a much higher threshold than Automation rules.
65 is just too low. Would love to see the components bumped up. (double?) At the very least, there should be a running count of components within the rule details.
Individual rules generally are harder, because it is difficult to "copy paste" between rules. Spitting rules is also cumbersome. Try deleting the top of the If/then rule. It takes out all the other Else-if options below it.
I find it very frustrating that Automation Rules are limited to 65 Components. I use a lot of branching and Logging to ensure data is being captured properly and don't like to have to split my rules up creating more to run on our Service Requests.
Happy New Year, everyone! May it be filled with joy, success, and - who knows - maybe even some miracles. Like Atlassian resolving to fix this bug. We can dream, right?