You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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.
If: all match
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.
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.
@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?
@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.
@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.