Need to think of a workaround for Jira Automation AND/OR ScriptRunner Limits

Zachary Howard
Contributor
November 21, 2024

Some background: Jira Cloud, Premium License. Our company uses a custom number field called Internal Priority. This field is used by management to determine which Epics are the top priority. We have a ton of these Priority statuses, each with their own meaning, so we cannot use the built-in Priority field. 

We have a prioritization meeting every week where management will update these numbers, and those updates will then get pushed to Jira in bulk. Our teams need the internal Priority number on each child issue because they view and sort the child issues on a Kanban board that does not show the Epics. 

We had built an automation that will update all child issues Internal Priority field when the Parent Epic's Internal Priority field is updated. However, because we update over 100 of these Epics after every prioritization meeting, and each Epic can have between 5 to 80 children, we end up hitting the runtime limits in Jira Automations.

Attempted Solutions:

  1. More Automation Rules: We have already tried breaking our automation rule down into multiple rules based on the Internal Priority number, however the problem is that most of the Epics fall into one or two of these and those rules still hit the automation limits
  2. ScriptRunner Listener: We had purchased ScriptRunner, thinking that it would help us to bypass this limit, but we ended up running into another limitation thanks to Jira API Rate Limiting. This is because the trigger for ScriptRunner is set to when the Epic is updated. This causes all updated Epics to trigger at the same time, which pushes too many API calls (to update the child issues) at once. I even programmed in a wait time to compensate for this and it still ends up failing. We cannot split this automation in ScriptRunner because the limit is for the API, and not the individual rule like in Jira Automations.
  3. ScriptRunner Scripted Fields: I thought this might be a viable solution, however there is another limitation here where the Scripted Field will only update after the issue is viewed in Jira by a user. Since we need to use this field for reporting and filtering using a Scripted Field won’t work.

Any suggestions or tips that we could look into to solve this problem?

 

2 answers

0 votes
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.
November 23, 2024

Hi @Zachary Howard 

However you solve this, if the Epics are updated during teams' working hours, I suspect there is already a visibility problem: because of the time needed to update child issues, priorities will shift while teams review them on the Kanban boards.  I suspect a process change may help more than trying to solve this with automation rules.

 

I hypothesize you are encountering two limits with the automation rule approach you describe:

  • With so many Epics updated quickly, that triggers multiple instances of the same rule, and that hits the upper limit of "Number of rules that can run at the same time"
  • Because of that, the continual processing to catch-up exceeds the "Daily processing time" limit, resulting in a THROTTLED error, halting rule executions for the entire site.  (This is in addition to any other automation rules trying to run for other reasons.)

 

As you have already tried breaking up the execution with multiple rules, that likely ran into the same situation.  An alternative would be to use multiple rules, on staggered scheduled triggers with JQL to limit scope, and checking using an additional custom field (e.g., Internal Priority Update DateTime) on the Epics to limit execution to "today".  That will certainly be difficult to tune and will still fail if there is any automation outage that delays execution on the schedules.

 

As a process change alternative, have you considered re-ordering (i.e. ranking) the Epics in response to the change to your Internal Priority?  If that was done, the Kanban boards could use swim lanes based on Epics to order the child issues, assuming the board filters use an ORDER BY Rank ASC clause.  This approach eliminates the need to cascade the field value down to child issues.

 

Kind regards,
Bill

0 votes
Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 21, 2024

Hello @Zachary Howard 

What specific Automation limits are you hitting, and what automation rules have you configured when hitting those limits?

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events