Branches within automations

[Vijay Dadi]

Hello There,

I stumbled upon one of the scenario, where in i had to use nested branches within an automation and that is not possible.

Another one was I am already under the branch but there is no option to have If-Else section.

Have you ever come across this scenario, if so how did you manage it or is there a plan in future to have implement these features.

Vijay

[Mikael Sandberg]

Yes, I have multiple automations were I needed this, and the way I solved it was by using a main automation as the dispatcher that then calls other automations via the incoming webhook trigger. It does increase the number of automations you have, and knowing which one calls another one can get confusing if you do not have it documented. I use databases and a whiteboard in Confluence to document automations.

[Rodney Dsouza (Atlassian Certified Expert)]

The 2 scenarios you mention are seriously annoying limitations.  It was not easy to find but here is a page that documents this: https://support.atlassian.com/cloud-automation/docs/what-is-rule-branching/         I certainly hope Atlassian improves on those 2 items - I have heard rumors that they working on enhancing these sort of limitations.

I believe Atlassian wants to limit how complex Automations rules get because it they take a lot of compute power.  But they already have a 65 component limitation per rule and we end up needing to just work around this (and other limitations) by doing more complex rules that end up doing the same thing and probably taking up more computing resources.  

For example, when I need to to a IF-ELSE block within a branch (1 of the 2 scenarios you mention),  I just copy the entire branch using the handy copy-n-paste icon and then do the opposite action (assuming in the this case that there is only one/two if-else - if more then I copy-n-paste multiple times.. sigh).  But this works, and so I am glad.

If they just allowed IF-ELSE within a branch the 65 components per rule could still be enforced.  So both Atlassian and Admins could be happy.

The nested branch within a branch could also be allowed but in this case Atlassian may have more difficult time enforcing that we don't abuse things.  Currently the max amount of items per loop is 50 (I did not find a page that documents for all loops, just AQL type, but it does seem to be for all loop types), and so theoretically a nested loop could balloon that to 2,500.   But I do believe other limitations could still enforce that we don't abuse this.

What Mikael suggest about multiple rules via web requests / webhoohs is also useful, and it comes with additional complexity that necessitates additional documentation.  I do use that when I need to overcome the 50 item loop limit.

I have also found that using this specific kind of conditional operator to be helpful:

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-conditional-logic/

Basically it is like a "ternary operator" in some programming languages.  For when you need to set a value based on 1 of 2 conditions, you can prevent duplicating branches.   To see how to use this, see my example at the bottom of this page: https://community.atlassian.com/t5/Jira-questions/Clearing-a-Assets-attribute-via-Automation-error-when-attribute/qaq-p/2757280?utm_source=atlcomm&utm_medium=email&utm_campaign=mentions_answer&utm_content=topic

Here is a page that documents a lot of the limitations: https://support.atlassian.com/cloud-automation/docs/automation-service-limits/