Automation: transitioning issues based on linked issue status

[Jonathan Fleig]

I'm working on a global automation in Jira Cloud that is scheduled to run on each business day that checks if a linked issue status has changed. I understand how powerful some of these automations can be and would just like some others that are more familiar with automation to take a look. 

The idea I'm trying to accomplish is to take issues from one project, look for a linked issue that matches from another project and specified issue link type, and check the status. If the status doesn't match, transition the triggering issue.

Trigger

• Scheduled
• Run rule every 1 week, Mon-Fri
• Run a JQL Query = true
• JQL Query
  • project = "project_name_a" AND issueLinkType = "is caused by" AND statusCategory != Done

If: all match

• Linked Issues
  • Match Types: is caused by
  • Match specified JQL
    • project = "project_name_b" AND status = "Backlog"
• Status does not equal "Preparing"

Then

• Transition the issue to "Preparing"

The If/Then repeats two more times with very similar conditions checking for the different statuses and trying to make them match. Is there a better way to write this, or does this seem sound enough to work without causing things to happen on other unintended issues?

The first Query in the Trigger is yielding the results I would expect. The second query in the If statement is yielding more results than I expect, however they do match the query as expected. I want to make sure that only issues found in the first query are the issues being changed.

[Ryan Northfield _Mumo Systems_]

@Jonathan Fleig 

As I'm looking over this it looks like a good design. The issues from the first query should be the only ones changed. One question: why are you limiting the "Match specified JQL" to just checking for a backlog status? Is that status the only one possible that the linked issues will be in? 

I ask this because this automation is hard coded to just work on that one status "backlog" to that one status "preparing". 

[Ryan Northfield _Mumo Systems_]

I'm guessing that the reason the second query is yielding more results that you expect is because it isn't limiting the results to tickets linked to project_name_a issues. The "validate query" operation is just running the query itself, not its condition context. I hope that makes sense.

[Jonathan Fleig]

@Ryan Northfield _Mumo Systems_ There are actually two more repeats of the "If / Then" in the full automation, each looking at two other statuses and transitioning those accordingly. Since they were repeats I didn't think it was necessary to include in the original post, but I can certainly add those in.

I think you're correct that it is not considering the condition context above it. I guess my question is will the automation consider the context above it?

[Ryan Northfield _Mumo Systems_]

@Jonathan Fleig Yes, it will.

[Jonathan Fleig]

@Ryan Northfield _Mumo Systems_ thank you so much for reviewing this--I really appreciate it!

[Ryan Northfield _Mumo Systems_]

@Jonathan Fleig As an alternative suggestion, you could have the transitions happen more in real-time by triggering the automation based off of an issue transition.

Condition: if linked issues of type "causes" are present, then

Branch into the linked issue and transition the status there to the status of the triggering issue. 

You could hard code the statuses here, like you did above, or you could create a variable, store the value of the triggering issue, compare each status of the branched issues, and then set the status if the status doesn't match (see below image). This would make the automation status-agnostic with just one condition check, without having to check for each status individually. (Now, there may be issues with this if admins add statuses to one project later on that aren't on the other.)

This would probably be heavier on the system since it will run on every issue transition, but I thought I'd suggest it.

[Jonathan Fleig]

@Ryan Northfield _Mumo Systems_ I do have a separate automation that runs as issues are transitioned, and it is limited scope to the project type where the triggering issues are located. For the scheduled automation, this is intended to capture the issues that get linked later and perhaps the user did not change the status appropriately. In my example, Project A is actually a Feature Request project, and Project B is a development project. If we have an issue created for feature A already, and a new feature request comes in for that same feature, the user would link it to the development issue that already exists. This scheduled automation then updates the status of the new linked issue so it is inline with the development issue. From there the development issue becomes the trigger to updated the linked issues.