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:
Any suggestions or tips that we could look into to solve this problem?
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:
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
Hello @Zachary Howard
What specific Automation limits are you hitting, and what automation rules have you configured when hitting those limits?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.