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; } } }

Trigger tasks whenever a subtask's status is changed

Martina

Hey all, I was wondering if you know what's the most automation-efficient to trigger tasks whenever a subtask’s status is changed.

I have a short amount of automations allowed, this is why I am asking.

I have been doing that the trigger was:

“When ANY task is transitioned to Done” and condition IF task = subtask AND summary = “Summary Description”.

But this might not be the most efficient way since tasks will be moved to done a lot, and I don't want the rule to be run every time, otherwise I'll loose automations.

Every time a subtask is created it already has a unique # / ID. Maybe I can reference that unique field instead of creating a second number for it? But I don't know exactly how this is done.

P.S. it will also need to work for tasks that are no longer subtasks but LINKED tasks - which will happen because I would like to move subtasks into different projects.

Thank you so much in advance!

Accepted answers

Martina

Hey @Bill Sheboy @Walter Buggenhout I wonder what you think about this if you have the time:

So just to reiterate, I'm building a rule that changes the status of a subtask whenever the status of another subtask changes. Here's the code, but the problem is that there will be multiple subtasks matching the issue summary, since there will be one per task, so I wonder whether you have ideas on how to check whether these 2 subtasks belong to the same parent or task.

Thanks!

All comments

Walter Buggenhout

Hi @Martina,

A rule is only counted towards the execution limit when it performs an action. So, just triggering it does not necessarily count towards the limit.

Having said that, that does not mean you should get careless of course. It will be important to define more precisely what you want to automate ...

In general, if you start with an issue transitioned trigger, that is just the first step. You can further refine with conditions until you get exactly what your need:

Adding the appropriate target status (done) in your trigger will be a first refinement;
An issue fields condition on issuetype = subtask is a second possible refinement
You might be able to restrict the automation to a limited set of projects
...

until it only fires in that limited number of cases where you really need it to.

I think the very first thing you need to do is go to the drawing board and be very specific about the logic.

One more thing about the following quote:

Every time a subtask is created it already has a unique # / ID. Maybe I can reference that unique field instead of creating a second number for it? But I don't know exactly how this is done.

That does not really make sense if I read it. You don't create numbers - you create issues in Jira. And indeed, there is absolutely no need to create an issue if it is already there. It would make more sense to do something else with that existing issue: update a field, change it's status, ... whatever it is that you want to do. But still: whether your automation rules create an issue or updates an existing one doesn't make a difference against the amount of executions.

So once more, try to be specific about what it is you want to automate; define it in common language and only then try to find the best way to implement it in Jira.

Hope this helps!

Bill Sheboy

Hi @Martina

Adding to Walter's answer...

There are specific rule actions which count toward automation usage, not all actions. Please review this article to learn what counts, and perhaps how the limits spanning all of your Atlassian products can be utilized to mitigate the packaging changes.

https://www.atlassian.com/blog/announcements/cloud-automation-packaging-update

Kind regards,
Bill

Martina

Thanks to both! I'll try to refine it!

Martina

Hey @Bill Sheboy @Walter Buggenhout I wonder what you think about this if you have the time:

Thanks!

Bill Sheboy

First, if this rule should only process for subtasks, please add a condition after the trigger (or add to your JQL condition) for issuetype = subtask.

Next, do you want to find the one which has the same parent issue? If so, please add that to the JQL for your branch.

Martina

yes! I want to fint the one with the same parent issue, but how do I do it? I thought something like issue.parent.key = triggerIssue.parent.key but it doesn't work.

thanks for getting back @Bill Sheboy

Bill Sheboy

For the branch, please try adding this:

AND parent = {{triggerIssue.parent}}

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-cloud