Automation: Branches are not working as described

[Kruno]

Hey peeps,

I am a heavy Jira Automation user and it enabled us to speed up and improve a lot of processes. My point in this question is if I am being stupid or if some of the available Issue Branche actions are actually described wrong.

I am using a rule to create some issues incl. Sub-tasks at a defined time. As both tickets are the same but need to be created for different Projects I thought I can simply create one and then clone it. Of course I know that I have to change the parent > child relationship.

After hours of fiddling around it just won't work that way. I changed branch types and positions of them up an down. The issue I see is that the branch "All created Issues" and "Most recently created Issue" are not working as defined.

Below you can see parts of the rule. underneath I simply use another Branch of type "All created issues" and create sub-tasks for each one. Doesn't work. The outcome are two issues and one of them (the top and first one created) incl. the needed sub-tasks. The other one doesn't.

Happy for any input.

Cheers

[wwalser · Accepted solution]

Automation rules do not wait for a branch to finish before executing subsequent actions in the rule.

For example, in a chain of automation components that looks like this:

TriggerA -> ConditionA -> BranchA -> BranchB -> BranchC

Branches A, B and C may execute in parallel. 

Based on the configuration in your screenshot, I believe you expect the branches to wait for one another, thus allowing the "most recently created issue" and "all created issues" to be aware of the issue creates that occur inside branches. This is not the case.

I wonder if you could do all of the creates outside of a branch, in the mainline execution of the rule, then have a separate rule which runs on "when issue created" which puts those resulting issues into the correct state?

It's a bit of a tricky use case. 

[Bill Sheboy · Accepted solution]

Hi @Andie Duframe 

Would you please post your entire rule and an audit log for where you see the problem?  That may provide some context.  Thanks!

Regarding the branch execution, I wonder if you have hit an edge case.  Please consider this documentation: https://support.atlassian.com/jira-software-cloud/docs/work-with-related-issues/

In that documentation it states:

Ordering of branch executions

• Branches on multiple issues (such as 4 sub-tasks) will run in parallel with no guarantee one will finish before the next one starts. Therefore, you cannot rely on changes between branches.

• Branches on multiple issues are run as a new process, with the main branch continuing execution before the sub-branch starts.

• Branches on single issues are run inline, to maintain performance. Therefore the main branch will not continue execution until the sub-branch completes.

The first branch you show would seem to be the third bullet (single issue), and so run inline and block the rest of the rule processing until completion.  And you clone an issue in the branch.  I believe that your re-fetch action has nothing to do with the created or cloned issue, but instead refreshes for any originally triggering issues.

What are you expecting the scope of the next branch's "Most recently created issue" to be: 

• the first created task in the SDL project, or
• the cloned task in the ASP project?

What do you observe happening in the audit log entry you have in the second branch?

Best regards,

Bill

[Kruno]

THX. Both of you nailed it I think.

I saw the "Ordering of branch executions" section but I will be honest - I found it very complicated described and I didn't understand what it means at the end of the day for the detailed execution. Maybe because I'm not a native speaker!?

Moving it into multiple rules could be an option but does seem cumbersome esp. also as I will not have enough criteria to distinguish this issues from others and it also defies the reason I am trying this - not having to have multiple rules but one as I had one in the past, one for each project these issues are required for.

At the end I must say that I think that my main point is still valid. If there are no guarantees about which branch is executed when, how can I then call the branch "All Created Issues"? I know that technically it is correct but from the user pov it is simply wrong as there is no guarantee that all the issues you expect exist at this point.

[Bill Sheboy]

For your use case where you appear to want sequential processing after the issue creates, you can try what @wwalser suggests by eliminating the branches. 

If that will not work, the alternative is to use multiple rules, where the creation of the issues sets an indicator in them which you can detect to trigger a second rule to finalize processing.  When using that approach, the second rule should enable the Allow Rule Trigger setting in details, as that will: "Check to allow other rule actions to trigger this rule. Only enable this if you need this rule to execute in response to another rule."