Automation for Jira, accessing a variable from outside of a branch

[Jeffrey Bistrong]

I am not sure if this is intended or it is a bug, but I wanted to share and see what others think. 

I am trying to create a variable inside of a branched JQL lookup and then use that variable outside of the branch.

Referring to my below screen shots, I was trying to access Variable A in the "Advanced Edit" at the bottom of the automation rule (which was located outside of the branched rule.

You can see in box #1, logging the action produced no result.

However, when I added Variable B (at the top) before the branched rule, it then changed something which then allowed me to access variable A outside of the automation rule (refer to box 2) which shows the log action. 

Below are screen shots of the entire automation rule if anyone wants to see what I am doing. The custom field 10800 is the Teams field that comes from Advanced Roadmaps, and has limited functionality inside of the automation tool, so I must manually manipulate it. 

[Bill Sheboy]

Hi @Jeffrey Bistrong 

TL;DR: the variable goes out of scope because of how branches work, and so is null.

Apologies in advance...I tried to write a shorter answer for this and was unable to do so.  :^)

Branches which can only be on one-and-only one issue (e.g. on Parent, on Current Issue, etc.) are actually run in-line.  And so it is like the branch did not exist (except to help with conditions).

Branches which could be on more than one issue (e.g. JQL, linked issues, etc.) are run in parallel and asynchronously.  And so...there is no guarantee of when the branch will finish, until right up to the end of the rule.  Stuff that happens inside these branches remains so, except for any issue updates, web requests, etc.

Putting these things together, let's look at an example:

• trigger: some trigger which has an issue
• action: create variable named varBeforeBranch
• branch: on Current issue
  • inside...varBeforeBranch as a value
  • action: create variable named varInsideOneIssueBranch
• outside of the branch...varBeforeBranch and varInsideOneIssueBranch have values
• branch: on some JQL
  • inside...varBeforeBranch and varInsideOneIssueBranch have values
  • action: create variable named varInsideTwoIssueBranch
• outside of the branch...varInsideTwoIssueBranch has no meaning and so is null

The original community post on create variable, which I cannot find, showed an example where a variable was created before and then inside a branch, and successfully used later.  That was a bit misleading as the branch was a one-and-only one issue type.

Often work-arounds for this design need are to rethink what you are trying to capture and use divide-and-conquer (with multiple rules) or lookup issues/objects to sum, average, etc. the data.

Kind regards,
Bill

[Chiranjib B]

Hey @Bill Sheboy 

Were you referring to this example, that you consider misleading?

My use-case is, I want to aggregate efforts logged by each team (hence branching out once for each team) and then compile them into a confluence document (using the custom web request action)

I am failing to propagate the desired info as I desire, would you have any suggestions for me?

[Bill Sheboy]

Hi @Chiranjib B 

Yes, that is one of the examples.

For your use case, perhaps one of these approaches would work:

1. advanced branch on your different teams list; use a lookup issues action to gather the information you want on the Confluence page call the web request for the Confluence page
2. lookup issues to gather the information needed; use if/else structures for each team, and smart value filtering to gather the results needed; add a single condition to test for presence of the data, and then call the web request for the Confluence page change/create

Kind regards,
Bill

[Marc Isikoff]

If I am reading this correctly, we can branch on current issue, create a variable in th branch using JQL to ensure it has a singular value, and then use that variable within the branch and should be fine.

Meaning if we can guarantee we are getting one epic (I am trying to find a key for a single Epic and assign that to the issue as the epic link) it should be possible?

[Bentley_ Andrea]

I know this is an old question, but I think I have the answer. Any variable created within an IF Branch or a FOR Branch will not be in scope outside of the branch. However, if you create the variable at the very beginning and give it a default value, you can then give it a new value within your branches, and it will be in scope anywhere in the automation.

When I run the automation and check the audit log, the value of myVar is the value set in the branch.

[Siree Chambers]

Brilliant Andrea! That works beautifully!

[Volkan Haralali]

Hey @Bentley_ Andrea , thanks for the amazing solution. Works like a charm also on Data Center!

[Duzmath Lajos]

@Bentley_ Andrea

Is this still working? 
I cannot get it running in my Cloud instance.

 
Inside the branch, the value is set to this:


After the branch, in my log I still get this value:


So the value of the variable does not change :(

Your help would be highly appreciated, this is blocking 2 of my important developments.

Thanks in advance!

[Bentley_ Andrea]

@Duzmath Lajos your Audit Log shows that your For JQL branch is not executing - that's why the variable value doesn't change.

[József Danka]

Thank you Andrea! Amazing solution, this is exactly what I needed.

[Danielle Alota]

Hey @Bentley_ Andrea  - hoping you could share some further light into where I'm going wrong.

I'm trying to find the team that a user is in via group membership. Steps I'm thinking:

1. Find group that contains "RBAC" that user belongs to. (eg. RBAC-Payroll)

2. There is a team named just "Payroll" (different to group name).

3. Find that team with another API call (not captured in image)

At the moment, I'm having trouble pulling out the group name out of the for-each loop that iterates through all the groups. 

First {{groupName}} has empty. Second {{groupName}} has RBAC-Payroll (confirmed with first log). But then second log still prints empty. Any ideas? 

[Bentley_ Andrea]

No, sorry - I have no idea! It looks like it should work? When you create {{groupName}} the first time, are you setting the value to an empty string?

[Manuel Bernardino Marques da Silva]

@Duzmath Lajos 

Happy new year and sorry to bother!

This indeed seams to not work anymore, did you find a solution?

Thanks

[peter.guyver]

This also isn't working for me

• Created a variable (before) a For each branch
• Inside the branch, use a condition to then create a variable with the same name
• (After) Outside the branch, the variable doesn't get replaced/updated

I know my condition works because I'm using audit logs to verify what the variable should now be.

[József Danka]

@peter.guyver

In our case this trick worked (still does) but we have found out that in some certain situations (like using it for a specific function) it does not work for whatever reason and a workaround was needed for those cases.
for example:
https://jira.atlassian.com/browse/JIRAAUTOSERVER-1165#

Could be the same issue for you as well.

[Bentley_ Andrea]

You're correct - I just created a short test automation, and it is not maintaining the value set within the branch. I guess they changed that? And... now I need to go verify all my automations...

[Bentley_ Andrea]

@József Danka hey, thanks for that link! It says it was fixed? In versions 11.3.2, 10.3.16 but those are both Jira Server, and I'm on Jira Cloud. :(

[peter.guyver]

Same here, Jira Cloud

For my use-case, I'm trying to use automation to look up options in a custom field, so I wanted to branch/loop over the options (JSON response), check if one already exists, and update the variable to say it exists or not

In the end I just joined everything in the list, into the variable, comma separated, and used a condition to check if my value was in the variable. No branching and no If Else.

Works but would of been nice to use branching.

[Glenn Dobbelaere]

I knew this was working, so I was quite surprised (and a bit scared) when it suddenly didn't anymore.

Since there is quite a divide between people where updating of global variables IS working, and people where it IS NOT working, I decided to investigate my use-case.

I found something interesting and a bit disturbing. It seems that using certain actions "breaks" the variable's scope.

In my case I was using the "Send web request" action. Here is what I found:

When NOT using the 'Send request action':

 

When using the 'Send request action':

 

In the first case the globally scoped variable updates just fine from the "if"-branch. However, when the 'Send web request' action is used, even if the result is not updated and the variable it set to something else directly, it will show the original value on the main branch.

I'm not sure if this only happens when  using the 'Send web request' action, but I'm afraid this might not be only action that can potentially break variable scope.

This makes Automations VERY unpredictable. I have already wasted hours in the past trying to figure out why an Automation does not work as expected, and the reason always seems to be because of something finicky or unexpected like this.

[vincenzo.spatafora]

Hi @Bill Sheboy,

so, are you saying it's not possible to store a specific/single field coming from a JQL branch into variables? Such that the variables can be used later on to make calculation?

Can you please see my question in here and support me:

https://community.atlassian.com/forums/Jira-Service-Management/How-to-store-a-custom-field-coming-from-bulk-process/qaq-p/3150227#U3151053

Thanks in advance,

Vincenzo.