Seems unfair to both limit how much a rule can do but then also bill on how many rules run

Joseph March 7, 2024

So Jira Automations have a limit of 65 components per rule, and per this KB, it's not as simple as one step = one component (we found this out recently when trying to dynamically update fields from an external DB for our issue tracking)

https://confluence.atlassian.com/jirakb/automation-rule-message-you-ve-reached-the-maximum-number-of-65-components-allowed-per-rule-1295385946.html

 

so now not only do we have to split our automation into multiple ones and run them separately, we're also being limited to how many automations we can run 

https://www.atlassian.com/software/jira/pricing

 

Feels like a scam given that we've seen the execution time that the "maxed" out rule takes, which makes us wonder where this "65 component" limitation came from

 

1 answer

0 votes
Walter Buggenhout
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 8, 2024

Hi @Joseph,

I am not going to argue about the sentiment of fairness you are expressing. I can understand that.

On a side note, 65 components in a single automation rule is a lot. If a rule with so many components does not exactly do what you would expect it to do, it is terribly hard to debug and adjust. I am quite sure that other factors determine the limit on the number of components allowed in a single rule than forcing you to have more rules you can be billed for. 

Joseph March 8, 2024

Maybe the community has a better way of doing what we're doing then?

 

We have custom fields for a project that we base other automations on depending on the content.  Those fields need to align with a database that collects results (external platform)

 

Right now, we have to make an API call to the external platform, then parse out the response to create smart variables (right now we're only able to query for 9 fields) for each field

 

We then have an If loop that compares the smart variable to the issue field and if it's been updated, we update the field and comment on the issue.  For debugging purposes, we also log the change in the audit log

 

So that ends up being a real basic 4 step loop that results in 5 components for each custom field (of which we're trying to mirror a dozen fields) 

 

Unfortunately due to the nature of the testing, any of the dozen fields can change daily and we're using the change to trigger other automations within Jira, so it's not like we can just do a full overwrite daily (plus that would end up causing the automation count to rise since that'd be many runs that actually take an action vs most of our runs resulting in no change when nothing needs to be updated)

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 8, 2024

Hi @Joseph 

Based on your additional scenario information, I believe you can compress some of that logic down a bit...

This approach would use conditional logic to update (or not) a field using advanced edit with JSON syntax.  Similarly the text for the comment could be dynamic.  I would expect this to reduce from 5 rule components per field to 2 rule components for all fields.  There might be exceptions for a few field types, but the vast majority should work this way.

To learn more about these rule techniques, please look here:

The tricky parts of this technique are:

  • correct formatting of the JSON expression to ensure there are no stray / missing commas, and
  • ensuring the detection of field differences works for each type. 

These can be experimented with repeatedly, by writing to the audit log rather than editing or commenting, until the syntax works as expected.

Kind regards,
Bill

Joseph March 8, 2024

Thank you, I'll take a look

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PERMISSIONS LEVEL
Site Admin
TAGS
AUG Leaders

Atlassian Community Events