Advanced Branching: Web requests using objects in a list

[Jimmy Tracey]

I am having trouble getting my Advanced Branching to perform actions over every object in a list (currently performing the correct action on the first object in the list). Currently, I use a Web Request to GET the Form IDs of all Forms in a ticket. Then I need to send a Web Request to change the visibility of all the forms to 'Internal'. Currently, it will change the visibility of the first form but wont perform the action on the rest of the objects in the list.

I have attached screenshots of my workflow and the logs I'm receiving to show exactly my issue. 

[Bill Sheboy]

Hi @Jimmy Tracey 

After your first Send Web Request, please try writing this to the audit log:

The response id values are: {{webResponse.body.id}}

That will confirm if the response message's body contains a list of values that can be parsed for the id attribute.  And you expected that result to contain a CSV list only.

If it does not, it should help to identify how to parse the response.

Kind regards,
Bill

[Jimmy Tracey]

Hey Bill, thanks for the help. Here is the response;

It looks to be a list of parsable values, however when I try to perform a 'For each' using advanced branching it only performs the action on the first value.

[Bill Sheboy]

Thanks, Jimmy.  That seems to indicate it is a list which can be iterated.  Let's confirm that with this write to the log:

The number of id values is: {{webResponse.body.id.size|0}}

This should be the count of the id values in the response, which was 4 in tests.

[Jimmy Tracey]

Correct, 4 responses

[Bill Sheboy]

That indicates the branch is correct, and as @Rebekka Heilmann _viadee_ noted the dynamic URL may be incorrect as {{Form}} for your branch only contains the id value; there is no attribute of id needed.

[Hariharan Iyer]

Hi @Jimmy Tracey ,

I think the smart value in your advanced branching step - webRequest.body.id is only returning the first id. Can you try something like this

{{webRequest.body.id.asJsonStringArray}}

instead?

Please check this documentation for more details.

Hope that helps!

[Jimmy Tracey]

Hi! I tried this and this was the response: 

[Rebekka Heilmann _viadee_]

Hi @Jimmy Tracey 

Can you show the "For each" in detail? Depending on what you're branching over you will need to access a certain depth in the variable. 

My guess is that currently the branch doesn't split the Web Request response into seperate values so it will only run once on position 0.

[Jimmy Tracey]

Hi @Rebekka Heilmann _viadee_ , 

Here are some screenshots which demonstrate how I'm using the 'For each'. Do you think thats the issue?

[Rebekka Heilmann _viadee_]

Hi @Jimmy Tracey 

not sure where the Variable comes from now as it's not shown in the first screenshot, but that shoudn't make a difference.

The Webrequest will give you multiple Forms in a Comma-Separated List. Therefore, can you try to first split the List and then access the ID?

So for the For each/Branch:

webResponse.body.split(",") -> save into variableA

And then access the ID via {{variableA.id}}

[Jimmy Tracey]

Hey @Rebekka Heilmann _viadee_, sorry for the confusion, I have removed the variable.

I have tried your method as shown in the screenshots below, however it looks as if this has broken the Branching as now all branching actions dont turn up in the logs. 

[Rebekka Heilmann _viadee_]

What happens if you print "Form" now first thing in the Branch?

[Jimmy Tracey]

This is the response from the following log;

[Rebekka Heilmann _viadee_]

The log means, that the branch works and {{Form}} only contains one ID at a time. Exactly what you needed. The Log Action is a bit weird as it's printing everything in one row if there are now other actions in between.

Try the WebRequest with {{Form}} rather than {{Form.id}}

[Jimmy Tracey]

Hey Rebekka, thanks for responding!

Unfortunately, I tried this and got the same result. Please note in the screenshot I sent above listing the {{Form}} values the white space between the 'Form=' and the value. Do you think that could be the issue?

[Rebekka Heilmann _viadee_]

The Log Action is fine and works as expected. The space there doesn't matter for what you want to achieve. You need to edit the WebRequest.

So you will have the branch and the Webrequest after that like:

[Jimmy Tracey]

Hi @Rebekka Heilmann _viadee_ and @Bill Sheboy,

Thank you so much for your help so far, really appreciate the time you're putting in to help me. Unfortunately, I have made the changes you have outlined and am still receiving the same result. I think as I have changed my code to attempt different contributors assistance it is worthwhile for me to send my entire workflow again. 

If I input for the branch as @Rebekka Heilmann _viadee_ has shown above the branching breaks and the logs I receive back don't include anything from the branch;

If I put .id in the branch then it performs the action on the first Form in the list but not the others;

[Jimmy Tracey]

Additionally, If I remove the .split from the branch it also works in the same way (performs action only on first object in list);

[Bill Sheboy]

Hello, all!

Short version: I believe there is problem with the first Send Web Request action inside of the branch.  This could be validated by: reviewing the action for errors; or copying the rule, removing all branching, and explicitly only trying to update any form except the first one (such as by saving the second id value from the first request, and using that later).

Focusing on what can be observed from the audit log just posted:

• The branch correctly works iterating over {{webResponse.body.id}} 
  • We know this because of the multiple logged values of "Form=an id value, Form=another id value..."
  • Thus the split() function is not needed in the branch source
  • Since this has been verified, I recommend removing those writes to the audit log before the branch
• When there are multiple id values for the branch, all records are processed, but only the first one correctly sets the form to internal
  • We know this because the log shows each webResponse body, with only the first one changed to internal=true  (They appear as a CSV list in the log.)
  • However, there is nothing in the log to indicate if the second Send Web Request action inside the branch succeeded or failed, as it's response status is not logged

What we cannot observe...

• The entire rule has not been posted, and so we do not know what the trigger is, or if there are any other actions not shown...particularly inside of the branch
• How long the rule execution is taking; the image of the audit log is truncated
• It is unclear if all Send Web Request actions have enabled the "Delay execution of subsequent rule actions...", and so we could be in a race-track condition

[Jimmy Tracey]

Hi Bill!

Sorry for the late reply. I have copied the rule, removing all branching, and explicitly only tried to update any other form except the first one. Like you guessed, the status of the form did not change. 

I've attached screenshots of the entire flow and the runtime of the automation. Additionally, I can confirm that "Delay execution of subsequent rule actions..." is enabled for all Web Requests.

It must be an issue with the Web Request! But why would it work for the first form but not the others?

[Jimmy Tracey]

[Bill Sheboy]

That inline test to toggle the other form's visibility failing helps narrow things down a bit, however...

I note in the documentation that REST API function is listed as experimental, so I wonder if there are known problems not listed: https://developer.atlassian.com/cloud/forms/rest/api-group-forms-on-issue/#api-issue-issueidorkey-form-formid-action-internal-put

And...someone in the developer community also reported problems with that function when toggling visibility: https://community.developer.atlassian.com/t/help-unable-to-toggle-jsd-form-visibility-to-internal-external-via-rest-api-v3/76679

At this point, I recommend contacting the Atlassian Support team, which you should be able to do as a the site admin for a paid license: https://support.atlassian.com/contact/#/

When you hear back from them, please post what you learn to benefit the community.