Automation in Jira Cloud when a certain type of linked issue transitions to a done state
Asked by Russell Zera:

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 ([https://support.atlassian.com/jira-service-desk-cloud/docs/when-if-and-then-statements/](https://support.atlassian.com/jira-service-desk-cloud/docs/when-if-and-then-statements/ "JSD-Automation - When If and Then statements")), but I have been having a difficult time finding that in Jira Software Cloud


Answers:
author: Curt Holley
body: 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 issues...do 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.

comments: author: Russell Zera
body: 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 :-)


author: Curt Holley
body: 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](https://community.atlassian.com/t5/image/serverpage/image-id/115368i7711A71D9AB25061/image-size/large?v=v2&px=999 "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???


author: Russell Zera
body: 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?


author: Curt Holley
body: [@Russell Zera](/t5/user/viewprofilepage/user-id/1019319) 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!!


Tags: cloud

jira-cloud

jira-software-cloud