nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Automation - Execution counts towards limit.

Jonathan Cunliffe

Hi,

Using Jira Standard, I have an automation rule to keep statuses of cross project issues in sync. Simple enough.

Screenshot 2021-06-16 140837.png

However, every time an issue is transitioned, regardless of it matching the criteria, and within any project, the rule runs and counts towards one of my 500 executions per month. So in two days I have exhausted all 500 global rule executions and not once has the rule actually executed to completion.

This seems very wrong.

Have I missed something in specifying the rule correctly?

Thanks,
JonC

Accepted answers

Jack Brickey

No you aren’t missing anything. Unfortunately executions are counted regardless of success or the conditions. It is based on a trigger if the event triggers it decrement your 500 count.

All comments

Clark Everson

Hi Jon,

Can you screenshot the audit log if there's anything there. Also have you yourself made any other rules. Also do you have other automations in your instance? Unless you're on Premium the 500 rule is for all users. With Premium it's 1000 per user, not per software. So the limit may have been caused by another user. If this is a tool you use often you would want to look into Jira Cloud Premium.

https://community.atlassian.com/t5/Jira-questions/Jira-Automation-usage-limits/qaq-p/1331233

Best,

Clark

Jack Brickey

No you aren’t missing anything. Unfortunately executions are counted regardless of success or the conditions. It is based on a trigger if the event triggers it decrement your 500 count.

Bill Sheboy

Hi @Jonathan Cunliffe

Yes, and... to what Jack notes about the global/multi-project execution limits, I wonder how you are using that automation rule.

Your rule describes linked issues in multiple projects, and when one issue of Dependency type transitions, all of linked issues do also. That seems to indicate those issues are just for visibility rather than for tracking work progress. In that use case have you instead considered a shared multi-project board (in a company-managed project)? Dependencies could be viewed and there would be no need to use global rule executions.

Best regards,

Bill

Jonathan Cunliffe

Hi Clark,

Here's the log.

Screenshot 2021-06-16 175721.png

This is the only global/multi-project rule we have as can be seen in the usage log.

Screenshot 2021-06-16 202325.png

I'm guessing it's just the way it is with the Standard subscription however it doesn't seem to be the fairest policy from Altassian considering my rule never actually got executed to full completion.

Jon C

Jonathan Cunliffe

Thanks gents. I've not come across multi-project boards so will look that up.

You're right in your suggestion Bill in that the dependency issues are just for visibility. Project A has a task (A) that is dependent on project B. PM of A creates two dependencies, one in each project and links them. They also link their task (A) to the dependency issue in their project. The PM of B can see another project has placed a dependency on them and can link and control the activities to meet that dependency in full, isolated control of project A. Reporting is very easy and can show all in/out bound dependencies. The automation comes into play when the dependency is 'Done' or perhaps 'Cancelled' and syncs the status between proj a and proj b.

I thought this was quite an elegant and straight forward solution to the eternal nightmare that can be cross project dependencies. Without the automation it can still of course work but just requires someone to remember to change both of the dependency issues. Not the end of the world but pound to a penny it will get forgotten.

Cheers,
Jon C

Bill Sheboy

Thanks for explaining, @Jonathan Cunliffe Regarding the "multi-project board", what I was suggesting was something like the following for the shared board:

Rather than use an issue type of Dependency, link the issues which are dependent. Perhaps creating a link type of "dependency", or using the existing "blocks" and "is blocked by"
Create and save a filter for impacted issues

project IN (project-A, project-B)
 AND issueType IN (story, bug, task)
 AND issueLinkType IN ("dependency")
 AND statusCategory != Done
 ORDER BY Rank

Create a new Kanban board based upon that filter, storing it in a company-managed project
Adjust the board's status mapping to reflect how you want to summarize/visualize workflow between the teams

This board shows the open, dependent work. When you need a report on that, use the same saved filter. And, the project managers would not need to create issues in each other's team project, only create/manage the links.

Matthew Rochman

This is not good....

I have just come from an enterprise DC version of Jira to Cloud. In my previous company, we obviously had unlimited executions, but the cloud version has limits. I suppose that's fair as they don't want their servers to be slammed by people running endless automations all day.

However, when an issue is 'processed' by the rule and the outcome is "No Actions Performed", that shouldn't count as an execution. Nothing happened, nothing changed....!!!! Only "Success" should be counted.

This is a big problem because there's some triggers where I cannot narrow things upfront very much so it ignores more tickets and doesn't process the automation. If an trigger is "when an issue transitions to Closed", it will pick up loads of tickets that don't qualify for the automation, but i can't do anything about it as far as I can see.

Have people come up with approaches that somehow help narrow things "at the front door" so it doesn't pick up so many?

Bill Sheboy

Hi @Matthew Rochman -- Welcome to the Atlassian Community!

I expect this will be a case-by-case thing, and so you may want to create a new question, link to this one, and post images of the rule and audit log you are trying to improve.

In general, using the project scope rules does not use up any global/multi-project execution count...but may require more maintenance if the same rule is needed for different projects. All rules have the limitations on execution time/hour and so a run-away rule can still be a problem.

I recommend considering the problem being solved for each rule and that may help to constrain the targeted issues/sprints/etc. to the minimum needed for triggering and execution.

Kind regards,
Bill

Matthew Rochman

Thank Bill,

But my issue is the fact that Atlassian is counting a cross-project execution as one where no action was taken. In my scenario and others, the automation starts with a broad trigger (an issue is created or a transition is done), then next step it checks whether the ticket met certain conditions, but when it picks up that the ticket does not meet conditions and nothing needs to be done, this is still counted as an execution towards the monthly limit. I say that this is ridiculous to be honest!

If a gas meter reader came to my house and saw that I had used no gas in the last month, I don't expect to receive a charge for someone to read the meter and realise nothing was technically consumed.

If we had the ability to configure the trigger so that it completely ignores many tickets from the outset, that would be fine. But in the case of Automation for Jira, we don't have a choice but to start with a broad trigger that catches everything.

An example I have which is a sensible automation that should be included with Jira - When a person transitions an Epic to "Closed", the Epic Status should also be changed to "Done" so they remain aligned. Many users don't realise there is an Epic Status on top of the workflow status, so I am happy to put in an automation that keeps them aligned at the end stage. No one closes an epic but wants to keep the epic visible on the backlog.

So when I setup this automation to run on all projects, the trigger I seem to need to use is "when an issue is transitioned to "Closed"" .... There have been around 3 epics closed s in the past month where the automation actually took actions and did its job. But there are about 800 tickets closed in the last month that weren't even Epics, but they are counted towards my limit because they are caught by the trigger.

This is the issue. But hoping someone has come up with workaround solutions to this.

Jack Brickey

Hi @Matthew Rochman , yep I get it. When I first realized the count was on rule execution and not rule success. However, after living with it I feel it does make sense to count on the rule triggering and assessing the conditions. I too would like to see some more narrowly focused triggers or an increase in the count. Or maybe some free library rule, e.g. the Epic status you mentioned.

for now the only work around is to build rules for specific projects yielding unlimited executions. I have found this to work well for all of the "expensive" rules. Not ideal especially for large instances but doable.

Guaraci Nakamura

Hi. These two automations below have been consuming the "Executions" limit, and I would like to know if any of you have some recommendation to consume less.

Captura de tela 2022-05-17 105139.png

1) When a Story issue is created, a standard text is included in the "Description" field. The problem is consuming "Executions" for all created issues, including subtasks. PS: Initially I was wondering to create a new custom field with a standard text (e.g. "Description 2"). However, I gave up this option because the project has some years and already has thousands of issues, so replace the current Description field to the new one would mass this fields once contains not only text but pictures, tables.

Captura de tela 2022-05-17 104748.png

2) Attribute to the "Start Date" field the date when one of 5 types of issues are transitioned to "in progress" or "dev doing" status. The problem is consuming "Executions" for all created issues, including subtasks.

Captura de tela 2022-05-17 104200.png

Bill Sheboy

Hi @Guaraci Nakamura

I believe you have 3 options, each with costs/benefits:

Upgrade to a higher license level with more global/multi-project rule executions per month. (Cost: licensing fees, benefit: no rule modification needed)
Copy rules to each relevant project (when possible). (Cost: maintenance work to sync rules, and benefit: reduced global executions)
Analyze and then modify your rules to reduce triggering. (Cost: rules do not trigger as fast as condition occurs, and benefit: reduced global executions) For example, ensure the relevant issues are uniquely identifiable and then use scheduled rules with JQL. Even though the rule checks on each scheduled time, it will only trigger when there are issues to process. A key part of this solution approach is including a stopping condition.
- For a specific example with your issue transitioned rule, add a comment, custom field flag, etc. so that the rule will not re-process the issue again later. This approach is more reliable than using the JQL DURING operator for issue transitions...because if there is another long Jira outage there is no guarantee the rules will run all missing executions during the outage window.

Kind regards,
Bill

Guaraci Nakamura

@Bill Sheboy How do I do "ensure the relevant issues are uniquely identifiable and then use scheduled rules with JQL."?

Do you have any recommendation on how to trigger less issues ? Today all issues are triggered.

What stop condition would you recommend?

Bill Sheboy

Hi @Guaraci Nakamura

This is going to be case-by-case, depending on your rule purpose and trigger...

For a made-up example, let's say I wanted to set a custom field, myCustomField, when an issue transitions to "In Progress".

First I would write JQL to find issues matching that criteria:

project = myProjectName AND status = "In Progress" AND myCustomField IS EMPTY

Thus once the field is set for a specific issue, it would never be found by the JQL again. Then I could use that JQL with a scheduled trigger to find/update the issues desired.

Please look over your use cases to determine if such an approach would work. I suspect it will for both of the cases you described.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

automation