When you tired, it’s 9PM on Monday …


Respond to PowerApp or flow action doesn’t get triggered. I wonder why…


I’ve got two actions leading to Respond to a PowerApp or flow is the outcome of the Scope in case of a success and a failure in the parallel branch.
What I am trying to achieve here, really, is to pass a result variable regardless of the result of both actions.
Here we have to pay attention, because the magic doesn’t happen automatically.
This is how it looks by default:

You may think “Easy! I will tick all checkboxes and happy days!”

I did. Not good enough.
In case of Failure the second condition will be satisfied but the first one will be skipped because it’s gone to the Fail branch but it has to be Succeeded according to the screenshot for Respond to a PowerApp or flow action to be triggered.
Crazy! Crazy for 8PM on Monday. What do we do?
We click on all checkboxes until we see all values appear for each action as per the screenshot below.

I would say “Easy!” but said many bad words prior getting the result which satisfied me.
So … It’s good I could get it working.

Hi Olena,
I’m interested to know why you would use a parallel branch here instead of a Condition. As I understand it, by ticking all of the options, your “respond to a PowerApp or flow” action will execute even if the preceding variable is set to ‘Fail’. Is this the desired behavior?
if you were to use a Condition instead of a parallel branch, then you can ensure that the respond action will only be triggered if the preceding variable has been set to success.
Unless I’ve mis-understood the requirement of the process – in that case, please ignore! π
LikeLike
Hi Matt,
Sure π
Let’s say I pass Work Order ID to the child flow. I expected to be well-formatted GUID but what if it’s not. What if something in a parent Flow is screwed and something else is passed instead? We use scopes and parallel branches to handle partially failed actions. I don’t want it to stuck if it’s failed for some reason. I want it to always retrieve the result to a parent Flow. How condition would help me to handle Get Row by ID exceptions?
LikeLiked by 1 person
Ahh OK, that makes sense to me now. If I had built that flow, the set variable to success would be contained within the scope. if the scope was failed, have an action to set the variable to fail. But if the scope was successful, then the set variable to fail would be skipped. Then you can pass the variable into the same way that you are doing in the screenshot.
If you needed to process a get row by ID – I would use a condition on the length of the output of the get row by ID action. If the length > 0 then we got a record successfully.
I’ve not thought of using parallel branches the way you are using them here before. I like the idea though.. π
Regards
LikeLiked by 1 person
π will be checking your length for the output idea but I feel like it just gonna tragically fail. I mean action :). We use my colleague, Mira’s (@curious_mira) magic monitoring tool to log issues to a Sharepoint list This is the bulk email generation so you don’t want it to fail badly on one item We log issues instead and trying to process as many records as it’s possible.
LikeLiked by 1 person
Understood. The joys of trying to make sure that Power Automate can highlight an issue, but then continue..! I like the idea of logging out to SharePoint. I do the same to a custom table in Dataverse, so I can link to the record that caused the issue more easily. But logging out to SharePoint is also a great solution!
LikeLiked by 1 person
We struggle with data storage at the moment. Logging to Dataverse is not an option for us, unfortunately.
LikeLiked by 1 person
What is this magic monitoring tool by @curious_mira that I have been reading about in the comments? Is it available to try?
LikeLiked by 1 person
Yes, it’s really good! I will let you know when she bloges about it next
LikeLiked by 1 person