JIRA Automation edited field availability

[Michael Oltmans]

I am trying to do a branch limit 1, I am attempting this by trying to allow the first issue in a branch to pass a condition so I can use the value created to trigger another automation. The problem I am running into is I am using a lookup based on the field I edit to stop and subsequent loops of the branch from running. The lookup on the second go acts like the issue has not been edited and so it returns nothing the second pass and allows it through. 

If it is the case that JIRA automation si NOT actually updating the issue at that moment and is in fact waiting is there some other way around this problem? I can not believe they don't have a limit for there JQL branch search. 

Other things I have tried is using smart variables BUT apparently JQL Branches don't HOLD the value in a variable....

Is there a way past this? I feel like if there isn't then someone needs to be fired over there cuz these are realllly basic items here.

[Bill Sheboy · Accepted solution]

Hi @Michael Oltmans 

Looking at your rule, a couple of things to note:

• Branches which could process more than one issue always run asynchronously.  Per the documentation, there is no guarantee the branch will complete execution before the other steps of the rule finish.  Branches which absolutely evaluate to one-and-only-one issue are run inline and complete prior to any other steps in the rule.  (e.g. Current issue and Parent)
• Considering the above, created variables go in/out of scope as a branch proceeds.  So the single issue branch is the only time you may depend upon a created variable's value persisting to the next step.

I am not fully understanding your use case, and it seems like for a set of issues you want the branch logic to execute only for the first issue found.

If that is the case, you could use a Lookup Issues action with JQL and an ORDER BY clause, grab the key for the first issue found, and branch specifically on that.  Note that will run asynchronously as it appears the rule's branch parsing is not clever enough (yet!) to understand key=ABC-123 can only return zero or one issue.

Kind regards,
Bill

[Michael Oltmans]

The use case for this is that when a issue has a start and end date of 1 - 5 I want to force any issues and subsequent issues out of that range. My idea is to use the first issue i.e. the one with the greatest days so 

Issue 1 - 1 - 5

Issue 2 - 2 - 3

Issue 3 - 3 - 4

I want to use issue 2's start and issue 1's end to get 3 days and use that 3 to push all tickets with a start date greater than issue 1's and push them all out by 3 days. This pushes out Issues 2 and 3 AND everything after that point.

If you have a good idea on how to do that I'd love to hear it. I am going to try your idea first.

[Bill Sheboy]

Hi, Michael.

Thanks for the additional details as those help explain it.

This is quite a complicated use case to implement in an automation rule, and it would be simple in a tool specifically meant to adjust scheduling.  Anyway...

First thing: will this use case ever encounter more than 100 issues in the chain?  If so, automation will not work as Lookup Issues, Branches, and Scheduled triggers have a 100 issue processing limit.  There are work-arounds, but they are brittle solutions.

Next, given the asynchronous branching behavior, you would need to be quite careful when implementing this, and I recommend creating/testing this rule in a test project.  Remember the order and timing for completing the work in a branch is not deterministic, so you cannot know that that "Issue 27" will be processed after "Issue 26".

An example rule that might solve this could be:

• Whatever trigger you are using and conditions...
• Use lookup issues with JQL to find your "Issue 1" (in your above example), and store the relevant values in created variables
• Use lookup issues again with JQL to find your "Issue 2", and store the relevant values in created variables
• Use a branch on JQL to find the other issues to update (excluding Issue 1's key from the results)
• Update the issues.  I would first experiment by writing the values to the audit log and not performing the edit to ensure it works as expected.  Then add the edit action later.

Finally, perhaps ponder what problem this rule is meant to solve and that may give you other ideas to try before using this approach.

Kind regards,
Bill

[Michael Oltmans]

Thanks for the help!

So I actually completed it my mistake was not realizing that there was a man page for lists in jira automation separate from the documentation on lookupIssue. Once I found that page and read through it I had it finished pretty quick. Also with my setup once I use lookupIssues to get the first issue I calculate the days and everything that is picked up is pushed out by that amount of days.

For anyone who reads this post {{lookupIssues.first}} OR {{lookupIssues.get(0)}} both give you access to the values of the first issue retrieved with JQL.

Here is my final version of automation to auto move all issues out based on a single issues start date.

[Bill Sheboy]

Well done!