How to perform an action for each issue in "Lookup issues" query?

[anentropic]

The interface & docs for this feature are woefully under-developed.

It's not clear how to do simple things.

The "Lookup issues" action says you can:

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

If I follow that with a For Each branch step the obvious thing is that I want to loop over the issues I just looked up and perform an action on each of them.

But so far I can't work out how to do this and neither the interface nor the docs give any help.

I tried an "Advanced branching" step with {{lookupIssues}} as the "Smart value".

But when I try to save my automation I get an error:

This component may be incompatible

One of the following needs to be produced earlier in the rule by the trigger or with a 'for each' branch for this component to work: 

• Issue

In the "Advanced branching" step I had set the "Variable name" to "Issue"... so I don't know what is the problem here.

[Mikael Sandberg · Accepted solution]

Hi @anentropic,

Welcome to Atlassian Community!

The lookup issues can only be used as part of a list, you cannot use it in a For each loop. Instead you should use the JQL branch instead if you need to iterate over the returned result.

[Bill Sheboy]

Hi @anentropic -- Welcome to the Atlassian Community!

Adding to Mikael's answer...

The Lookup Issues action is the bulk-handling feature for work items selected by a JQL expression.  Its purpose is to sum / average / etc. values or to support bulk output, such as in a message or email.  The lookup results contain work item data, and so cannot be used with the work item actions, such as Edit Issue Fields, as they expect work item objects

To individually process a list of work items meeting some JQL criteria, either use the Scheduled trigger with JQL or a Branch on related items with JQL.  The one undocumented feature of the second type (Branch on JQL) is when the rule trigger provides an issue, that will be automatically excluded by the branch to prevent an endless loop / runway rule triggering.

Kind regards,
Bill

[anentropic]

Thanks, the validator let me save it with that change so it seems to have worked.

Has anyone at Jira put any thought into how users are supposed to discover the 'right way' vs these limitations?

[Bill Sheboy]

First thing, this is a community of product users, and not Atlassian Support, and I am just another customer participating in the community (i.e., not an employee of Atlassian).  If you have specific questions / concerns for Atlassian, paid license customers may contact them here or anyone may use the ? > Give feedback about Jira link in the products.

In my opinion...for many scenarios using automation rules, there are often multiple ways to solve a need, rather than a "right" or "wrong" way.  Instead, there are better or worse approaches, subject to the context.

Successfully using automation rules requires continual learning and experimentation.  As the product continues to evolve, there is no one-source-of-truth for all features.  Indeed, reading community posts and documentation, one will find new actions added every week!

My recommendation would be to create a test site / project and try things to experiment, and to regularly read the following to look for updates / issues:

• the documentation pages for each of the products which has automation features
• the template library of rules
• this community, watching for articles and questions mentioning automation
• the public backlog for suggestions and defects for automation
• the weekly release blog 
• the product status pages

[Dirk Ronsmans]

To add here even a little more.

While the JQL approach is the far superior one you should also be able to do it using the lookup Issues action.

Normally that would return a smart value {{lookupIssues}}, using that you could do a branch on a smartvalue, mainly "Advanced Branching"

https://support.atlassian.com/cloud-automation/docs/jira-automation-branches/

So both solutions would work while you probably have less hassle using a JQL.

An advantage of using a lookup Issues action might be that you can do it outside of a branch and then validate against the smartvalue if you should even jump in to the branch and if not provide a proper action as well.

[Troy Anderson]

Any tips for nesting a branch within a branch?  Specifically, when a version is released, I want to update the included work items (no problem) as well as certain related work items (can get the list but cannot update any of them).  Odd that branching can only occur from the root of the automation.  

Would this work?  Difficult to test since it is triggered by a release.

[Bill Sheboy]

Hi @Troy Anderson 

In the future, please consider creating a new question, and perhaps linking to earlier threads.  That will help focus the conversation on your specific scenario / concern.  Thanks!

For what you asked...there is no branch nesting yet.  And, variables created / updated in a branch over more than one item go out of scope when the branch completes...so your second branch would not work for several reasons.

Two possible workarounds for the scenario you describe are using dynamic JQL created from a lookup and chained rules:

Dynamic JQL (with one rule)

• Using Lookup Work Items with JQL, find the work items in your branch
• Using the work items found, generate a dynamic JQL expression which looks for both those ones and the linked work items meeting your criteria.

Depending upon how this is done, it may lead to a JQL expression which is too long to process, and so experiment with the two ways of doing this:

1. Simple: add the lookup keys and iterate to add a clause for issue IN linkedIssues("{{key}}", "clones")... for each one 
2. A bit more complicated: add the lookup keys and iterate and use a list filter over the issuelinks attribute of each one to add the additional keys.  This approach will only work for Jira Cloud, and not Server / Data Center versions due to limitations in the lookup results.

Either of those will produce a single JQL expression which may used in a JQL branch...if there are 100 items or fewer.  When there could be more than 100 items, use the chained rules approach described below.

Chained Rules (with two rules)

Using two rules...

1. Update your current rule so it adds some type of indicator to the work items in the version, allowing them to trigger another rule
2. Create a second rule, triggered on setting the above indicator, and which enables the "allow rule trigger" option in the details.  This rule iterates and updates the linked work items.

As a final note for testing: consider creating a test project, versions, and work items.  The rule(s) may be implemented and safely tested, and when done, copied to the production project.

Kind regards,
Bill