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.

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

[Jack Brickey · Accepted solution]

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]

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.

[Jonathan Cunliffe]

Hi @Bill Sheboy , this is terrific and I'll give it a try first thing.

Thank you, very much appreciated.

Cheers,
Jon C

[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.

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. 

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.

 

[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.

[Guaraci Nakamura]

@Bill Sheboy  tks!

[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.

[Bill Sheboy]

Matthew, thanks for clarifying, and I agree the triggers could allow more flexibility to restrict triggering.

For the common use case you noted of updating the Epic Status when an epic is closed, you could do this with a frequently scheduled rule and JQL (e.g. hourly) using Advanced JQL operators and would only trigger when issues are found to process.

project = myProjectName AND issueType = Epic AND status CHANGED TO Done AFTER startOfDay() AND "Epic Status" != Done AND status = Done

Just drop the project part (or add an IN clause) if you wanted this to be a global/multi-project rule.

[Matthew Rochman]

Hi Bill,

Think great minds think alike! 

About 20 mins after my last post, I decided to shift the trigger of the automation to a schedule. In this particular scenario, people waiting a short time for the automation to 'complete the job' was not important. 

As it can be triggered by JQL, I could refine it to a point where the trigger won't activate 98% of the time. So very much the same logic you described in your reply.

I also found a solution to another global automation. Previously, it was triggered when an issue was transitioned to Closed and then the condition was whether a particular new custom field (on the pop-up resolution screen when closing) was set to a particular value. 

I changed the trigger so it monitors for changes of any kind to this custom field on a transition. Again, massive reduction as the field had a single purpose and even if edited by accident when dealing with an issue, the field change trigger could be applied to scenarios where it was transitioned, not edited or created. 

This would only be applicable where a specific custom field is involved and would only be used in particular scenarios (I would not set a trigger based on (eg) when a Component was added or changed or some other commonly used field). 

So bit of extra thinking can perhaps narrow the automation trigger in some circumstances. I suppose it also needs a bit of 'big picture' thinking as well - for instance, if you jump to a schedule, you need to ask whether the automation really needs to run within 10 seconds of the trigger or if it can be delayed without causing grumpiness. 

Perhaps there's more. By the way, should I put the "question and answer" to this conundrum in a brand new post to make it easier for others to find?

Cheers and thanks again everyone here

Matt

[Bill Sheboy]

Yes, on the new question posting.  One way to get the most visibility of a question/topic is to post a new one and link to any prior ones...especially unsolved ones that have gone "stale".  Otherwise only the people following the old threads see what you add.

[Jack Brickey]

You might consider writing an article. These, written well, can really assist folks. 

[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

[Jonathan Cunliffe]

Hi Clark,

Here's the log.

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

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