Thank you, 43071b44dfdb .  That could be it.  In some of my child branches, I'm making API requests out to other web services.  Those branches seem to lead to the issue I was describing.

Because of this issue, we've decided to stop relying so much on Jira Automations and instead have started moving some of our workloads to Azure Logic Apps, which do seem to honor the flow and allow us more flexibility and do not have this same specific issue about variables being updated in if/else branches.

f0fcd7749d49 by the given description, it seems like you're having problem with block execution order.

I have experienced following my self:

• A block
• B block
  • C block (IF block or Branch)
• D block
• E block
• ...

Execution order goes something like this:

1. A (until done)
2. B (until done)
3. C and D (until done)
4. E...

try adding "delay" block at position D (after your IF block) and test the result of a variable in E block.

See if that helps  

Ran into this issue today.

We can create a variable outside of an IF block

We can edit that variable outside of the IF block (by "creating" it again with a new value)

We can use the variable inside the IF block

But if we EDIT the variable inside the IF block, then the EDIT is only visible inside the IF block (I just spent a few hours testing this. It appears that sometimes the variable is edited fine, and other times it isn't. Haven't figured this out yet).

And unfortunately, we need the ability to check a condition, and if true, reliably edit the variable for use back in the main line of the flow.

Within Service Management it is quite common to leverage both a reporter and a requested on behalf of field for tickets. In those cases, when we need to perform lookups on the person the ticket is 'for' we write an if/else block that checks on behalf of if they exist and checks reporter otherwise. We then need to use the output of those lookups, captured as variables, in future actions outside the block. It would be very helpful to have access to variables throughout the entire automation scope.

Hey, 13051b510827,
Hope you are doing well and sorry for the late response!

The variable is set within the IF Blocks based on different conditions and values. It is then used at the end, to et the Assignee but this does not work as the variable value becomes unavailable.

I had the similar scenario in my Automations and by accident I found this solution, could you try it and let know whether it works for you also:

1. First, you create the variable before the IF-ELSE block, let's call it MyVar. Give it some default value, e.g. 0.
2. Then, inside of the IF-ELSE block use the same variable name MyVar.
3. Print the variable outside of the IF-ELSE block.

This should give you a desired result.
I've just tried it and it works for me.

It seems I can't attach pictures here, but I could share it somewhere if needed.

Thanks in advance!
With kind regards
Slava

@SlavaGefen

We have a  Send Web Request action with several IF Blocks and a JQL Condition.  The variable is set within the IF Blocks based on different conditions and values.  It is then used at the end, to et the Assignee but this does not work as the variable value becomes unavailable.  

Hey, 13051b510827,

We are creating a variable inside if/else blocks but need the value to hold outside of the block

Could you please describe a part of your Automation where you are trying to use it? It might be there is a workaround for your case.

Thanks in advance!
Slava

We are creating a variable inside if/else blocks but need the value to hold outside of the block.  This is causing issues with auto-assigning issues because there are numerous conditions that must be evaluated.    The value needs to be accessible outside of the block.  

Due to this we found out that we can't comment just created in a branch rule issues.

And we need to use Send web-request action instead and set additional rule to receive the web-hook and comment on those issues.

For the example "use case", the work-around would be to use the Lookup Issues action (or a call to the REST API for issue search) to gather the issues, and then an iterator to produce the list of relevant issue keys.  However, rule limits mean such a rule could only match on up to 100 issues.

Most such "accumulator" use cases can be solved using these methods.

Perhaps an alternate use case that could not be solved with those work-arounds would be a branch on multiple issues (or values from a webresponse or variable) which performs complex logic to select a specific set of issues.  That use case also cannot be solved with smart value, list filtering, due to limitations in the use of smart values in many of the functions to help with filtering.  For example, date adjustments for customer-defined holidays in a list.