Branching over smart values in Jira Automation

[#1]

Hello everyone,

One of the most commonly asked questions we receive here in the Jira Automation team is whether or not it is possible to branch over smart values. We are very excited to announce that we have introduced a new feature, called Advanced Branching, which now allows this functionality! (Jira Cloud only)

Why would you do that?

Some of the use cases this addresses:

• Iterating over a list, such as a list of issues from Lookup Issues action, and performing an action on each of these issues

• Filtering lists using conditions to only perform actions on items which match

• Branching on any list or single object that is available in the smart value context, such as comments, versions, users etc.

How do I do it?

The Branch component now has two different branching options, the usual Branch rule / related issues, and the new Advanced branching

Selecting Advanced branching will present you with options to configure your branch. You specify the smart value you want to branch on, such as {{issue.comments}}.

Next, you specify a variable smart value name to use inside the branch, which will be the smart value you use to access the branched item. For example, if you were to branch on {{issue.comments}}, you might want to call it myComment.

Now, inside the branch, you can use the smart value {{myComment}} to access each comment in the list of {{issue.comments}}. The new smart value created is the full object from the original smart value, so you can access fields and methods on the branch object, such as {{myComment.body}}.

Where can I find more information?

There are a lot of advanced use cases this feature enables. For more information about branching and smart values, here are some documents which you may find helpful:

• Automation Branches

• What is rule branching?

• Smart values documentation

And of course, if you have any difficulties or want further information, please don’t hesitate to chat to us here in the community and comments below, or reach out via support.

Cheers!

Sam

[Vikrant Yadav]

@Sam Harding Thanks Sam!

Page Bookmarked.

[Manon Soubies-Camy]

Great news! That's a long awaited feature :)

[Bill Sheboy]

Thanks, @Sam Harding !

This could come in handy, as it appears to support a created variable as a source smart value, leading to generic loop processing or pulling apart just-in-time created lists.  Now if variables just had an edit action and Lookup contained all of the issue fields...  :^)

Keep up the great work!

Best regards,
Bill

[Darryl Lee]

Ha seriously @Bill Sheboy - how many answers have we written where the answer was, "Well unfortunately Automation can't do this right now..."

[Bill Sheboy]

Hi, @Darryl Lee Yes, and...automation can do quite a lot, and so helps often.  Bundled with the REST API and many problems can be solved.  There is room to improve and this article shows the team is doing so...We just gotta be patient for some of the requests to be considered as there are lots of great ideas out there.  Thanks!

[Simmo]

Hey @Bill Sheboy,

Can you run the edit variable action past me? Whats the use case here?

In terms of the lookup supporting all fields, the reason why it only supports what it does currently is performance. There are some fields that aren't part of the issue or that we need to fetch additional data from Jira for it to make sense. Until we can figure out a good way to handle this we've had to restrict it. You can imagine that if you did a search that brought back 100 issues and there were three fields that you accessed that needed more data, we'd need to hit Jira 300 times potentially, in a short window. That would make us not a good citizen :D 

[Bill Sheboy]

Hi @Simmo 

Thanks for your response!  Apologies for my wordy answer...  ;^)

I understand about the performance issues you note for lookup issues, and any fields that could be added would be appreciated.  I often note people asking about synchronizing things like start/due date and custom fields for parent/children...and although possible without having those fields in the lookup, rules would be simpler and shorter if the fields were present.

For edit variable, I can think a few use cases, including: improved clarity, shorter rules, accumulators, performance, and working around function limitations

• Improved Clarity: There is an edge case/work-around for created variable edit, which allows updating a variable inside of a branch, as described in this article.  This only works for branches on one-and-only-one-issue, so the branch in-lines (or so I understand).  Thus it isn't an edit...it is actually a re-creation of the variable at the same scope.  Having an edit would help people understand the distinction.  Of note, I do not believe this branching/update technique works for multiple-issue branches; they execute asynchronously, so any variable changes (create or edit) are lost when the execution goes out of scope...right?
• Shorter rules: Without edit variable, a work-around is to use multiple created variables to build up pieces of business problem answer, and then combine them later.  In some cases, the rule could become too long to implement by exceeding the maximum number of components.  Edit variable could help reduce that issue, and improve rule clarity by reducing "working variables" of extra created variables.
• Accumulators: With edit variable, a value which needs to be accumulated across several issues could require just one variable, rather than multiple variables and multiple lookups and branches.  (please see Shorter rules and Performance)
• Performance: One work-around for no edit variable is to update an issue field and then perform a re-fetch.  This greatly slows down a rule execution...and possibly causes unintended consequences/side-effects.  Having edit variable would eliminate the need for such a work-around.
• Working around function limitations: My experience thus far is rarely can created variables be used as function parameters or with some of the math operators.  Sometimes this can be resolved by using multiple variables to progressively build up an answer; sometimes there is no solution to a specific problem.  Solving the use of variables in functions is beyond the scope of your question, but I do see edit variable making it easier when work-arounds with multiple variables would work.

Thanks again for the work the team is doing to help!

Best regards,
Bill

[Brian Eschen]

@Sam Harding This is great! In my use case, I'm using this to create a new Story for each label applied to an Epic. However, I can't seem to figure out how to add subtasks to each of those new Stories. 

It would be really convenient to have another branch available so I can use the for Most Recently created issue type of branch. 

I get this error "Can't branch rule as it requires issues to have been previously created by this rule. More than likely you have not yet created an issue or the issue(s) were created in an another 'If' block or branch - these would then not be visible outside of that block/branch."

[Bill Sheboy]

Hi @Brian Eschen -- Welcome to the Atlassian Community!

You may want to consider posting your request as a new question with an image of your rule and the audit log.  That will give the community more visibility and context to provide you suggestions.  Thanks!

Best regards,
Bill

[Brian Eschen]

Hi @Bill Sheboy I did that here. Looks like I'm blocked by AUT-247. 

[Simmo]

@Brian Eschen , the description of AUT-247 does have a suggested work around if that helps at all.

[Darryl Lee]

So hey @Simmo - will we ever see this feature ported to Automation for DC/Server?

We recently got approval to purchase Automation for Server, and one of the "selling" points is that if we start moving various workflow customizations to Automation, that might ease the eventual transition to cloud.

Thanks.

[Simmo]

Hey @Darryl Lee, that isn't something I can answer I'm afraid. However, I've pinged the server team and asked them to provide you an answer :)

[Julia Foden]

Hi @Sam Harding @Simmo 

Is it expected that advanced branching should work to iterate over a list of issue links? I have posted a question here with the error I got.

[Sam Harding]

Hi @Julia Foden 

The feature did not cover issue links, but we have just rolled out an update that now allows issue to be used with the feature. Thanks for the feedback with your error information!

Cheers

Sam

[Bill Sheboy]

Ping...any word back from the DC/Server team if there are plans to support this feature for automation?

Thanks!

[Simmo]

Hi @Bill Sheboy

I've pinged them again.

[Bill Sheboy]

For those who have not heard: created variables can now be used as function parameters!  This will greatly simplify rules, and open up lots of possibilities for advanced branching.

https://jira.atlassian.com/browse/JRACLOUD-75659

[Perla Miranda]

Can this loop work for numerical fields. For example, I have a custom field such as "XCount" and I want to create that many sub-tasks. But when I enter {{issue.XCount}} as the smart value, it only performs the action once even if that field is set to 5. I'm assuming it's because this field automatically gets converted to a list, so it would be comparing against something like [5] which would have a length of 1. Is there any way to pass this smartValue as the iterator?

[Bill Sheboy]

Hi @Perla Miranda -- Welcome to the Atlassian Community!

There is no loop counter yet, and how about a work-around to do this?  The following works if you are using Jira Cloud, as you will need the action Create Variable.

Essentially this creates a string of XCount characters long, and uses it to create the iteration source.  For example, "X,X,X,X,X" for a count of 5 loop passes.

• trigger: what you wish, let's assume manual
• action: create variable to initialize the looping values
  • variable name: varLoopValues
  • smart value: NULL
• action: create variable again, replacing the old value with your looping values
  • variable name: varLoopValues
  • smart value:

{{varLoopValues.rightPad(varLoopValues.length.plus(issue."XCount"), "X").remove("NULL").replaceAll("X","X,").substringBeforeLast(",")}}

• advanced branch:
  • smart value: {{varLoopValues.split(",")}}
  • variable name: varLoopVariable

How this works...

We are using your XCount to create a string of "X" characters, replacing that to add comma delimiters, removing any stray commas, and then splitting that list to work as a counter.

Kind regards,
Bill

[Perla Miranda]

@Bill Sheboy This worked great! Is there any way to make a list of integers instead of "X". While it doesn't matter for creating the subtasks, I wanted to use this varLoopVariable also for naming the subtasks. So imagine it's a book and each subtask is a page. I want to name each subtask "Page 1", "Page 2", etc.. Currently I can do "Page {{varLoopVariable}}" but this will always be X so I would like it be integers

[Bill Sheboy]

Hi @Perla Miranda !

Thanks for the reminder about this post, as I had figured a way to do the numeric counter and forgot this one.

My solution approach up to this point used the issue field to create a string of "X" characters.  What if we then iterated over that list and used the {{index}} of the list to solve the counter need?  To do that we :

• split it to a list
• get the index

{{#varLoopValues.rightPad(varLoopValues.length.plus(issue."XCount"), "X").remove("NULL").replaceAll("X","X,").substringBeforeLast(",").split(",")}}{{index}}{{^last}},{{/}}{{/}}

This will produce a 0..n-1 list of counters.  If you want this to be 1-based, from 1..n you use a math expression on the index in the middle:

{{#varLoopValues.rightPad(varLoopValues.length.plus(issue."XCount"), "X").remove("NULL").replaceAll("X","X,").substringBeforeLast(",").split(",")}}{{#=}}{{index}}+1{{/}}{{^last}},{{/}}{{/}}

The advantage of this math expression is you can modify it as needed.  For example, say you want to count 10, 20, 30...change it as needed.

Once this new value is in the created variable, the advanced branch works the same, splitting on the comma-separated values.

Kind regards,
Bill

[Martin Müller]

is there any chance for datacenter? 

[Alex F]

Is there a way to get a list of all the account IDs of all users mentioned in a comment so that they can be used in the advanced branching?

I can get one account ID using something like this:

{{issue.comments.last.body.match("(\[~accountid:.+\])").remove("[~accountid:").remove("]")}}

But how about a list of the account IDs of all users mentioned?

Maybe I can use advanced branching to get such a list?

[Bill Sheboy]

Hi @Alex F 

Contrary to the documentation on the match() function, I do not believe it can return a list.  Instead it finds zero-or-one value (e.g. the first one) which matches.

So the work-around is to split your comment on something first, such as with split("~accountid") and then adjust your match to grab the accountId values.  This will produce a comma-delimited list of the values.

Kind regards,
Bill