Update multiple issues, that are not linked, using Jira Automation

[Daniel Newman]

Hi,

I am trying to update (transition) multiple issues that are not linked to each other in any way through a manually triggered Jira automation rule.

The below article states that the lookup issues function within Jira automation can be used to achieve this and other things including "sending an email, Slack, or MS Teams message. It could also mean commenting, transitioning, or updating every issue in the list"

https://community.atlassian.com/t5/Automation-articles/Send-a-list-of-issues-in-Slack-with-Jira-automation-s-newest/ba-p/1411819 

When attempting to use the above function to process multiple issues only the trigger issue seems to actually update.

Does the lookup issues function only work for "Scheduled" automation rules or should it work with manually triggered ones to?

My rule is simply triggered manually, executing a JQL query, using some smart values from the trigger issue, using the "lookup issues" action and then using the "transition issue" action to transition all issues through to the next status in the workflow.

My rule identified 2 issues as expected, as shown in the audit log, but only updated the trigger issue leaving the other identified issue in the same status.

Any help would be appreciated.

Thanks.

[wwalser · Accepted solution]

Hi Daniel,

Automation team member 👋. Based on you answer to other commenters, I believe the solution is to use a branch action. 

Quickly, I believe this configuration is close what what you want:

I'll also try to explain a bit about how automation works so that, hopefully, cases like this are more clear in the future.

It helps to understand what is happening as a chain of components execute in an Automation. As each step executes, it writes any relevant details into what we call the “context object”. This is the object from which smart values are pulled.

Most automations trigger on some manipulation of an issue, so it is often the case that {{issue}} exists within this context object. Many of actions implicitly read this {{issue}} value to understand what issue to operate on.

In your case, because the automation is manually triggered on an issue, that trigger issue is the thing in {{issue}}. The documentation for the lookup issue action says the following: 

Search for up to 100 issues using JQL and include the results list in other actions by using the {{lookupIssues}} smart value.

Having issues in the smart value {{lookupIssues}} is useful if you want to mention them in a comment, email, slack message etc. However, as mentioned above, built-in actions implicitly read from {{issue}} which is still only the trigger issue.

The primary way to change the implicitly read {{issue}} smart value is by using a branch component. The way that branch components work is that they perform a lookup, either of associated issues or using JQL, then loop over all of the issues resulting from that lookup setting each one to the {{issue}} smart value.

I'm not sure that I've nailed this description so if you have questions as a result feel free to ask so that I can massage the description into a form that makes sense.

Hope that helps,
Wes

[Daniel Newman]

Hi @wwalser 

Thanks for your message, that makes complete sense.

I originally tried to use the branching rule but it failed with the error message below which I thought meant you can only use branching to identify and update issues that are linked to the trigger in some way regardless of whether you were using the JQL branch or not.

"Error searching for related issues. This is most likely because the following issues don't have a related issue of the type you specified. Try narrowing your search to only include issues that contain links to related issues:"

I presume from your explanation that I was wrong in my assumption here and must have made a mistake in the JQL that I hadn't spotted.

So just to confirm; it is possible to use the JQL within the branching rule to identify and update any Jira issue based on the JQL?

I have now implemented a new version of my rule aligned with the detail you have entered above and got this working.

The one thing I have identified it that the branch JQL doesn't identify the trigger issue even if it meets the JQL so you just have to do the transition on the trigger issue separately.

Thanks for your help it is much appreciated!

[wwalser]

"Error searching for related issues. This is most likely because the following issues don't have a related issue of the type you specified. Try narrowing your search to only include issues that contain links to related issues:"

This is the generic error when a branch's search returns no results. All of the built-in branch kinds (parent, child, sub-task, epic, linked issue, etc.) use JQL under the hood. In a JQL branch, the JQL uses is just more transparent.

The JQL that you provide has one or two modifications made to it depending on the situation

1. This is always added to JQL branches: `key != {{triggerIssue.key}}` — I describe why below.
2. This is added in cases where the rule is a part of a project specific rule: `project = {{rule.projectScope}}`

The one thing I have identified it that the branch JQL doesn't identify the trigger issue even if it meets the JQL so you just have to do the transition on the trigger issue separately.

Yes, we intentionally exclude the trigger issue when performing branches because if we don't many users will unintentionally process that issue twice. Glad you noticed that and managed to work around it.

[Daniel Newman]

Thanks for explaining this further it is much appreciated

[Bill Sheboy]

Hi @Daniel Newman 

Would you please post an image of your rule and audit log so we can see where you are having an issue?

Just to confirm, Lookup Issues can work for JQL anywhere in the rule.  Its strengths are the ability to create dynamic JQL based upon smart values, and to process the items as a single chunk, such as with sum of values.

For a scheduled trigger rule, you may use JQL and those issues are available for single processing, one by one.  The same is true for a branch used within a rule with JQL.

So, if you can write JQL to find your issues, you may use a scheduled trigger or branch to update them.

Best regards,

Bill

[Daniel Newman]

Hi @Bill Sheboy 

Thanks for your message and for explaining this.

I have now resolved this; I must have made a mistake the first time I tried to use the branch rule as shown by the error message in my response to @wwalser

Cheers

[Aiden Marriott]

Hi Daniel. are you creating a "branch rule" from the trigger that then rules the JQL?

[Daniel Newman]

Hi @Aiden Marriott

No I am using the "lookup issues" action within the advanced actions list.

I didn't think the "branch rule" would work as I thought that this only worked if the issues were linked to the trigger issue in some way?