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

[Joseph]

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

[Rafa]

@Joseph ,

Another option is that you skip the Automation and use the Jira API for the main heavy lifting of such integration and "sync"'ing with the external platform API. 

It does require a different set of skills than to simply add an Automation Rule, but it will give you much more flexibility, and it will be much easier to debug (debugging or simply "undoing" changes on Automation rules can be quite messy). 

So, if possible, I would advise to build some "bridge" that talks to both systems via the API, and keep the Jira Automations for simpler workflow tweaks.

(I also spent quite some time fighting with the automation rules and their limitations, and in the end implemented a much more powerful integration via API and in much less time).

Otherwise, maybe something similar to Zapier can help you to build such a bridge (and probably the cost of paying for multiple Zapier executions is lower than having to upgrade to Jira Premium just to run more Automation rules) 

[Walter Buggenhout]

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]

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]

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:

• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-conditional-logic/
• https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/

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]

Thank you, I'll take a look