I re-read the documentation yesterday and found that the match() function actually returns not the first occurrence, but all occurrences as a collection (if there are more than one occurrences), so it works. There is a nuance - you still have to use the split() function in advanced branching (probably a bug), but, in the end, everything is ok.
Here's what it looks like:
Or you can just try to use the following smart value in the advanced branching smart value field:
I've found that you can use advanced branching inside an if/else construct, but you can't do the opposite. It's a pity that I can't branch with if/else inside advanced branching, it might make it easier to create advanced automations.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
@Alex F thanks for the information on the split/match versus match/split ordering, and I am glad to learn you got it to work. At a minimum, it seems the documentation should indicate the function returns only text, and not a collection as stated, and so leading to using split later when needed. If it was a collection, we should be able to immediately iterate over it.
FYI on the rule structure of branches and if/else, there is a hack which involves creating both at the same level and then drag-n-drop to what you want. However that appears to be unplanned behavior so if you notice it I would avoid using that in a production rule.
@Bill Sheboy thank you for the hack, I tried to drag-n-drop if/else branch, but it can't be dragged 🤷♂️ All other elements move easily.
If it was a collection, we should be able to immediately iterate over it.
You're right, so I checked it carefully again and found that when you create an intermediate variable the collection is converted to text, so the best way to achieve the goal is to use match() function directly in advanced branching block (it just didn't work for me the first time, but now everything is ok):
So you can just use the following expression in the advanced branching block and then you can do whatever you want with each {{accountId}}:
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Another tip: when creating a variable (or naming one in advanced branches) use a name that is unlikely to match another smart value. That can help with maintenance and avoid the potential of collision with existing smart values from objects. For example, I always the prefix "var", such as "varAccountId".
@Bill Sheboy Hi, I asked a question earlier this year which is above in the thread. The answer was working perfectly fine. This is what I've had since then, but somehow, stopped working this week. Do you have any idea what could've caused this or how to fix it? It's currently messing up our process now and users are going in and manually editing it now.
Goal, create subtasks that are named accordingly such as "Module 1", "Module 2", etc according to a number given in a previous field.
Currently what started happening yesterday, If module count is X (e.g. 25), each subtask is named "Module 25". Instead of starting at 1 and increasing accordingly. Unsure what to do.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
I just retested with my original example rule and it works as before. I suspect that your Module Count field or automation rule have changed to cause the difference.
As this may take a bit of back and forth to resolve, please consider creating a new question for this, posting images of your complete rule and the audit log, and linking to this thread. If you mention me in that question I will see it when you post it. Thanks!
Until then, perhaps write the above smart value expression to the audit log to see what shows. That one drives the advanced branch looping; if it does not show the values increasing you can isolate the problem a bit.
Hey @Sam Harding and @Simmo - it's been a few years, and I cannot find a feature request/suggestion to "Bring Advanced Branching (over Smart Values)" to Server/Data Center.
Sidenote: After almost 3 years, it was cool to find movement on this:
@Bill Sheboy I've just come across your smart value solution for looping, it's exactly what I need, however I'm not able to get any results using it.
The field I am using is called "Number of parts impacted" rather than XCount, but the idea is the same, I want to loop through the number of impacted parts input and then depending on the number do something that amount of times (in this instance create that many new issues).
But the following code for the variable gives me a blank result every time regardless of the value in the Number of parts impacted field.
{{varLoopValues.rightPad(varLoopValues.length.plus(issue."Number of parts impacted"), "X").remove("NULL").replaceAll("X","X,").substringBeforeLast(",")}}
I was wondering if you might be able to shed some light? Thank you.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Without seeing your entire rule for context, the most likely cause is the smart value for your custom field is incorrect. When the wrong one is used, it can silently collapse to null in rules without any errors shown.
Smart values are name, spacing, and case-sensitive. And often the smart value does not match the displayed field name on the issue views. To identify the correct smart value (and custom field id) for any supported fields for automation rules please try these steps:
identify an example issue which has your field(s)
call a REST API function with a browser to search for your issue:
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Would you please post an image of your complete rule, images of the relevant actions, and the audit log details showing the execution? Those may provide more context to explain this symptom.
In fact I just tested to make sure that either {{issue.customfield_10055}} or {{issue.Number of parts impacted}} gives me a value in the comment and it does. So it's definitely not falling over on the field value.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
@James Smith -- I just saw your post in the other thread, and it appears you discovered the missing action to initialize the created variable to NULL. Is that correct?
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Advanced branching helps to loop over anything referenced from a smart value expression, such as from a lookup issues result. However, my understanding is the rule does not recognize the entity from the advanced branch as an issue within scope of the rule, and so actions like Edit Issue cannot act upon it.
Contrast that to a branch on parent, linked issues, JQL, etc., where we do not provide a Variable Name because within the branch, {{issue}} refers to the currently looped-to issue.
Without seeing your entire rule, consider instead using a branch on JQL for this case, as the same JQL that worked for the lookup can be used to drive the branch.
Manual trigger which is triggered from an Epic and the attribute "Meeting required" should be edited on Epic, their underlying tasks and their underlying subtasks.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Based on your rule image, that cannot work for your scenario:
it is unclear what the initial branch is using as a source, as the entire rule is not in the image
a lookup issues action is inside the branch, is not used, and will not be available after a branch: things which are created inside of the branch (e.g., the lookup) not longer exist outside
to do what I suggested earlier, change the branch type to use JQL (not the lookup), to directly iterate over the issues to edit
I recommend creating a new question, perhaps linking to this thread, including in your question:
what problem your rule is trying to solve; that is, "why do this"
an image of your complete automation rule, in one image
images of any relevant triggers, actions, conditions, branches
an image of the audit log details showing the rule execution
explanation how the rule is not working as expected
Creating a new question will ensure more people see it to offer suggestions, as only people following the older threads will see them.
46 comments