Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Automation in Jira Cloud when a certain type of linked issue transitions to a done state

Russell Zera Community Leader Oct 22, 2020

I want to have an automation rule in Jira Software Cloud that when a linked issue of "Caused By" Issue Link Type is transitioned to "Done" status, If that is the only remaining open ticket linked to this parent ticket of that issue link type, Then this parent ticket will update field X with resolution value from that linked issue and transition to status "Ready for Acceptance".

Can do it very clearly in JSD (, but I have been having a difficult time finding that in Jira Software Cloud

1 answer

0 votes
Curt Holley Community Leader Oct 22, 2020

Not sure I understand how or where the "Parenting" is in your scenario. Reads like you have a one to many linked issues setup, where the one "master" issue is not a parent, but simply has a number of linked I have that right?

My hunch is, this would be a lot easier if instead of just a series of linked issues, there was a hierarchy in play. Epic to stories or Story to Sub-tasks.

Russell Zera Community Leader Oct 22, 2020

Gah... don't even know how I switched to use "Parent"... lol... good catch/call-out... Yes... Here's the vision of what I'm grabbing for...

1) A Story (I'll call this issue "Build this Widget") has issue-link-type of "Caused By" (for example) to another issue (not in the same hierarchy (I'll call this issue "Service-Update" for reference), could even be in another project entirely.

2) "Service-Update" moves to "Done" status with a resolution of "Deployed".

3) "Build this Widget" sees this happen, and seeing that there are no other open issues of that issue-link-type of "Caused By", it transitions to "Ready for Acceptance" and copies the "Deployed" resolution from "Service-Update" to a custom field in the "Build this Widget" screen.

Clarification: I want this to be defined inside the project for "Build this Widget" (so a "Pull" automation) NOT something that the project that "Service-Update" is in, requiring it to send an automation call (a "Push" automation).

Hope this clears it up :-) 

Like Curt Holley likes this
Curt Holley Community Leader Oct 22, 2020

Best I can think of is run a scheduled job with JQL of:

issueLinkType in ("Caused By") AND status = Done and resolution = Deployed

Then use an "if else" along the lines of:

draft automation idea.png

Note: I used "is tested by" as the link type, but you would use your "Caused by" one.

Then use the "edit Issue" action to configure your step 3.


Worth a try???

OOOO I like that! I wonder if there is a recommendation from Atlassian on "not to exceed" frequency on automation schedules? I think the main interest is in having this execution happen as near-real-time as possible, but I could potentially leverage an "Alert" query I have done in the past for alerting notifications where people can subscribe to entire sets of data under a saved filter like: 

project = "Critical Project Z" AND issueType = "Customer Reported Issue" AND StatusCategory != Done and Status != "Ready for Release" and priority = Blocker and updated <= -15m and assignee is EMPTY

Then they subscribe to it with a recurrence of every 15 minutes, (without it sending an email if no results found). So this becomes a system that can alert people if there is a critical show-stopper customer reported issue raised that has not yet been grabbed by someone on the team to start reviewing...

SO that would translate to the query you shared modifying to this: 
issueLinkType in ("Caused By") AND updated <= -15m 

And then setting the scheduling recurrence to run every 15 minutes... Just concerned I'd bork the system performance lol.  Think that might work?

Like Curt Holley likes this
Curt Holley Community Leader Oct 26, 2020

@Russell Zera I think it could.

That was why I just opted for a schedule, as I couldn't think of another way to "trigger" the event.

I don't think it matters how often you run the schedule. What matters is how many updates it is likely to do per "schedule", as that is where the grunt is.

Plus, whether you intend it to be a single project, Multi project or Global automation. Particularly f you are not a premium customer and have to watch your Multi project/global executions.


Good luck!! 

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Atlassian Automation

Jira Automation: Sum Up Story Points Roundup (Initiatives -> Epics -> Story/Tasks -> Subtasks)

Hi Everyone, In this roundup we combine all the jira automation rules to sum up story points across different issue types. We start from the lowest level, summing up story points from sub-tasks t...

1,757 views 2 7
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you