Showing results for 
Search instead for 
Did you mean: 

Bug: "Respond to a PowerApp or flow" with boolean variable should preserve boolean, and not convert to string

When using "Respond to a PowerApp or flow" from a child flow, a response output of boolean (Yes/No on the screen) should preserve the boolean data type.


Unfortunately it returns a string,


causing a Set Variable step for a boolean variable in the parent flow to fail:


The variable 'Successful' of type 'Boolean' cannot be initialized or updated with value 'True' of type 'String'. The variable 'Successful' only supports values of types 'Boolean'.

Status: New
Not applicable

@Stevenfayers I was having the same problem. Then I decided I would return and integer instead of a boolean value. Then it happened the same, it wasn't returning anything.


So I decided I to cast my variable before returning it to PowerApps, like this:




And it worked, I got the integer back in PowerApps. I'm not making any further changes but you should try to cast the variable as boolean




Haven't tried it yet, but it might work. Nonetheless, I don't know why they changed the behavior in that feature, and then you just have to figure it out to make it work.

Frequent Visitor

@Anonymous  - Brilliant!!! Can't thank you enough

I just needed to cast bool(1) to fix this for Boolean

So strange I thought I was going crazy because the JSON looks like its sending the correct response... but I guess the body should not be holding the text.


None the less if you cast what you need in the reply field it seems to correct this bug and now the body shows the correct result.



Regular Visitor

Hi all, I am making some tests with this function as we have used HTTP calls in the past to execute flow from another flow but we are evaluating changing to this method instead. I have 2 little tests flows, one is the principal that calls the second one passing some parameters. I am passing string, boolean, number and date parameters as I'm interested in testing all the possible formats this feature will let us use.

This is the second little flow, the one receiving the parameters:


As you can see in the image, this one is waiting for string, then boolean, number, date and then a float, and this is the main one sending those parameters:


As mentioned, parameters are in this specific order, string, boolean, number, date and float formats, so there should be no problem with this except for the float parameter that is not supported with this feature. When I execute the main one calling the one receiving those parameters, the second one receive them in the correct format as expected as you can see in the image below:


And then the problem comes with the response feature that is getting those parameters and converting them all into strings:


This is obviously not how you expect this to work, as you would have to cast all the parameters back to the format you expect them in the main flow multiplying the work you have to do instead of just respecting the formats you have declared.

For me, I had cast/parsed the parameters received on the main flow just for some testing, using string(), bool(), int(), formatDateTime() and float() functions to get them in the dessired format, but this is not a thing I should do when expecting 50 parameters, I should not spend my time parsing them all this way:


I don't think respecting declared formats its a hard thing to do honestly, and this is just so annoying that I'm not sure I can recommend using this method right now.

Kudo Collector



While not ideal, you can also give it the expression of true or false, which will return the correct value.