Answered

Using Request trigger POST and adding another connection results in BadRequest errors

(0) Share

Report

Posted on by bbdata

I've created a flow to receive Twilio texts and process them per this documentation: https://derekgusoff.wordpress.com/2019/04/02/send-and-receive-text-messages-from-microsoft-flow/

It works well, until I add an action that uses an outside connection (Twilio send a text or SQL server). Once I add the outside connection and test again, the flow will not run and I see this error:

There's a problem with the flow's trigger. Fix the trigger, Learn more

Pic: https://i.imgur.com/W6TMgL9.png

Clicking Fix the trigger takes me to my trigger with the error BadRequest and no other info

pic: https://i.imgur.com/ytfh4lg.png

Troubleshooting: Removing the action using a connection fixes the flow I created new flows using SQL and they work

I have other Request triggers and they still work, HOWEVER they are GET

Removing the JSON schema from the trigger does nothing

Creating a brand new flow with just the trigger and SQL recreates the error

Expanding my trigger shows the message: Remember to include a Content-Type header set to application/json in your request. However the trigger doesn't have header settings so I'm not sure if this is related or not.

I'm pretty sure this has something to do with using POST, but my googling has revealed no answers. I can't wrap my head around why adding an action that uses a connection would cause the flow to fail

All responses (6)

Answers (1)

stybun 3 on at

Like (0)

Report

Re: Using Request trigger POST and adding another connection results in BadRequest errors

Thank you for this. I know this is going back a while, at this point. But I was able to use the suggestions here to get mine working. And the filter array suggestion was a nice upgrade to the original design as well!
bbdata 20 on at

Like (0)

Report

Re: Using Request trigger POST and adding another connection results in BadRequest errors

Update to this issue:

Sorry @jonathanford I didn't see this response so long ago. I believe something has been 'fixed' on this because I am starting a fresh process this year and have 0 issues using a simple HTTP Post trigger for receiving Twilio messages. I simply pass $formdata to a Parse JSON action and it works great; something that did not work previously. From there I can do whatever I need to; inserting the records into SQL, auto-replying based on conditions, etc. For any folks using SQL, if you want to speed up your message processing I recommend passing the JSON into SQL and using OPENJSON to parse the message and pull parameters for further actions versus multiple Filter arrays in PA.
jonathanford 68 on at

Like (0)

Report

Re: Using Request trigger POST and adding another connection results in BadRequest errors

You don't need any of this, and I found this thread because I was having trouble too. I couldn't get yours to work either, however.

I'm using triggerFormDataValue('Body') to get the Value of the Key "Body." I have a HTTP request then this is pulling the Body value.

What's incredibly stupid, and goes back to what you're saying in your original post. This works even storing to a variable until I try to use the variable. Even stranger, it was working. I tried to put it into production and it failed.

This almost certainly is something broken. My workaround is to use the List Messages under the Twilio connector and check the messages every minute and I store the message SID in an Excel file and check for new SIDs every minute. If it's not there, I store it in the Excel spreadsheet.
Verified answer

bbdata 20 on at

Like (1)

Report
Re: Using Request trigger POST and adding another connection results in BadRequest errors

Okay, I've confirmed this has been working for a few days:

Create a flow to receive Twilio texts (on Twilio, use POST and the address of the Power Automate trigger)
Add one action with HTTP POST that 'passes' just the $formdata array from the body to another flow using a POST trigger

Flow 1:

On the second flow, you 'receive' the $formdata array

Make sure both triggers have the correct JSON (I just used the sample payload option for both). The first flow should be the entire content of the json sent from Twilio. The second flow should just have the $formdata json which I'm providing below

{ "type": "array", "items": { "type": "object", "properties": { "key": { "type": "string" }, "value": { "type": "string" } }, "required": [ "key", "value" ] } }

On the second flow, you can follow the blog post advice on grabbing values, however, I have found it's faster to use Filter Array to grab the key / value pairs you need. Here's an example of getting the body of the text message. I initialize a variable, then filter the body for the key value that equals Body, then you can set the variable to value found in the output from Filter Array- PA will automatically wrap this in an apply to each (which is fine- it will only run loop once).

Might be better ways to do this but I get tired of writing expressions to grab JSON values directly so was nice to use the dynamic content.

From here you can add whatever actions you need- I have a response text action from Twilio as well as an upload to SQL.
v-bacao-msft on at

Like (0)

Report

Re: Using Request trigger POST and adding another connection results in BadRequest errors

Hi @bbdata ,

Looking forward to your solution, it will be helpful to many users. Thanks for being an active Power Automate Community Member!

Best Regards,
bbdata 20 on at

Like (1)

Report

Re: Using Request trigger POST and adding another connection results in BadRequest errors

Update: I believe I have fixed this issue, but will continue to test today and resolve it if everything looks good.

Assuming there was something on the Twilio sending side that I could not control, I setup a flow that simply receives and then posts to another flow. This allows me to control the body, which I think is the issue; I extract an array from the original body from Twilio and then pass just that to my new flow. I'll post screenshots later after more testing for anyone else that runs into this issue. For now though the second flow is able to use other connections.