Why does a Multi-project Automation Rule where no action is carried out count as an execution?

[Andy_Parry]

With Atlassian restricting Standard Plan JSD and JS customers from executing more than 500 Automation Rule executions per project per month, rules which execute but do not carryout an action chews up the monthly allowance and therefore renders a large portion of the highly valuable functionality of the Automation rule feature from being useful.

We have an SD project which clones issues to a Software project when they're escalated to the development team for investigation.

Our need for Automation Rules in this scenario is for comments added to the the SD project issue, to be also added to the linked issue in the Software project and visa-versa.

The rule we have created is "run when a comment is added to an issue" and has an If Block of "Linked issues present Types: All link types".

The If block was added as we're finding the majority of the comments on issues in the Service Desk project are on issues that do not have linked issues and therefore, correctly do not carryout the action of the rule.

However, as the rule has been considered as executed due to the trigger being invoked by the addition of a comment, our usage allowance is decremented even though no action has been executed.

Is there a different approach we can take to achieve the desired outcome without compromising our monthly ARU allowance?

Ideally, the ARU allowance is increased considerably or executions are only counted if an action has actually occurred. Maybe a combination of both might be more reasonable.

What we want to avoid is the need for a Jira Software user to have access to Jira Service Desk as it's much more efficient for the Jira software user to remain focused and manage their workload from within their Software project.

[Jack Brickey · Accepted solution]

Hi Andy, I’m actually a bit surprised here and need to do some testing to validate what you are seeing. Did you read this somewhere or just observe it? Historically I was using A4J lite and this was certainly not the case I believe otherwise I would have exhausted my 300 monthly limit every month which was not the case. How confident are you in this and how have you validated it? Have you perused the log? 

I agree that if a simple trigger = decrement then that is most certainly problematic. I will have a look and get back later.

[Andy_Parry]

Hi @Jack Brickey 

I'm observing it...

I have only just started using the Automation rules and have just the one rule set up as a multi-project rule.

I can see thus under the 'Usage' tab on the 'Executions used' panel, it states the same number of executions as the rule in the 'Usage in the last 30 days' list on the same screen.

[Jack Brickey]

So I did a bit of digging on this and provided some links to docs below that you might find useful. However, the bottom line is best captured by this snippet from the first doc link.

Editorial: This is most unfortunate and IMO, and leaves me disappointed. :-(

In Practice: This means those that configure automations must be on their toes and must be creative in how they construct rules. The more specific you can be w/ the trigger the better off you will be from a 'conserving automation limits'. For example - Global rules = bad, Issue Created = bad, Global rule that uses Issue Created = Very Very Bad

What is a rule execution?

Any time an event fires as a result of an automation rule you have enabled, it will count as a rule execution.

For example, if you have created a rule that fires whenever an issue transitions to Done, this will count as a rule execution. Even if the rule does not perform an action, as long as it has been triggered, it is considered an execution.

Links:

• how-is-my-usage-calculated 
• view-your-usage 

[Andy_Parry]

Thanks for digging that out @Jack Brickey 

I did read somewhere that rules, when executed, that create cross-product issues do not count as a rule execution.

I assume this exception is due to the use case highlighting a big demand.

I wait, in anticipation, for a reply from an Atlassian Team member to explain the reason Atlassian have imposed the restriction on multi-project rules and the likelihood of the restriction being relaxed in our use case of cross-product commenting on issues.

[Andy_Parry]

What I read is actually documented in the first link you posted: how-is-my-usage-calculated 

What executions count towards my usage?

One exception to this is the cross-product Issue create action. For example, if you want to create an issue in Jira Software based off an event in Jira Service Desk – this will count as a single-project rule, not a global rule.

Essentially, we're after the same behaviour for comments between cross-product linked issues, further improving the efficiency of communication between two teams through automation.

[Jack Brickey]

yep at least there is that. :-)

[Jim Edgeton]

@Andy_Parry I'm about 3-4 weeks into learning/loving Jira Automation, but I am encountering similar concerns as you with limitations on Global Rules. I was going to create my own post until I found yours.

It's a bit frustrating to see that every triggering event for global rules counts against my monthly usage, instead of just the events that match my conditions and perform the action. For example, I have a cross-project automation rule that performs an action in Project B whenever the Sprint field changes in Project A, but only for issues in a specific Epic (rule condition). Unfortunately, just looking at the trigger means every time I am sprint planning and moving other issues in/out of sprints, it's counting against my automation usage.

Could someone familiar with the Jira Automation software please answer:

1. Is there a way around every triggered event counting against usage? If not, what's the technical limitation? Does it come down purely to performance mitigation?
2. Is there anything in the Jira Automation roadmap that will track usage only against triggered events that actually execute the rule action?
3. Are there any plans to increase the monthly rate from 500 to something higher for Standard price tier?

I'm in an enterprise environment that uses Jira where I cannot justify to my senior IT leaders to double our Jira software price to go to Premium just because a handful of projects want to use Jira Automation.

Any help understanding more about current limitations and/or future plans would be greatly appreciated! Thanks!

[Jack Brickey]

Jim, I recommend limiting the use of global rules to those that truly need to be global and have limited trigger scenario. Liberally apply project rules.