A better way to work with form data in Microsoft Flow triggers

I was recently introduced to Microsoft Flow, a powerful automation platform, similar in concept to Zapier or IFTTT. Today I’m going to talk about how to nicely leverage HTTP Request Triggers in Flow when your request content-type header can’t be changed from x-www-form-urlencoded.

For one of my first Flow projects, I hoped to trigger some automation tasks via form submission from our Wordpress site using Ninja Forms and the super cool Ninja Forms Web Hooks add-on. The Ninja Forms Web Hooks add-on enables Ninja Forms submissions to issue calls to REST endpoints via POST or GET requests.

Unfortunately, one of the first things I discovered was that in order to apply the handy schema templates for data binding, the Flow HTTP Request Trigger requires a content-type: application/json header to be sent with the request. Ninja Forms Web Hook requests always come bundled with a content-type: x-www-form-urlencoded header. Browsing around a bit in Google it looks like there are a few other tools or situations where this is the case as well. I won’t name names here.

Applying a schema to an HTTP Request Trigger requires a Content-Type: application/json header

The best documentation and online answers I could find seemed to indicate that the best/only way to work with this data and pass it on to actions downstream was to manually extract form data using the triggerFormDataValue(‘FIELD_NAME’) expression in the action. That seemed… fine… but somewhat frustrating because the JSON schema templates provide really nice hints and can help you to avoid errors when setting up downstream actions — without having to look up the data model every time you need to reference an argument from the trigger. I really wanted to be able to work with this data just as if it were a JSON object (because… well… it should be!).

Ninja Forms allows us to encode args as a JSON string, but that doesn’t change the content-type header of the webhook request.

So here’s where the magic happens. Instead of applying a content template/JSON schema in the HTTP Request trigger:

• Leave Request Body JSON Schema field empty in the HTTP Request Trigger.
• Use a Compose Action to convert the form data body to a JSON object using the expression json(triggerFormDataValue(‘JSON_VARIABLE_NAME’))

I renamed my Compose Action to “Convert Form Data to JSON” so I knew what it was doing.

This expression transforms the formData argument from Ninja Forms into a handy JSON object.

• Feed the output of the compose action into the content field of a Parse JSON action and apply the Schema you normally would place in the Request Body JSON Schema of the HTTP Request trigger.

Output from the Compose Action should be a valid JSON object.

Apply your Schema/Data Binding Template to the JSON

• The output of your Parse JSON action is now a nicely mapped/bound set of Dynamic content properties that you can apply anywhere in your down stream actions. Voila:

And there you have it, no need to manually extract your form field properties using triggerFormDataValue(‘ARGUMENT_NAME’) every time you want to use a property from your form in actions. The form data has been transformed into a usable JSON Schema mapping and bound to Dynamic Content fields, without touching the content-type: x-www-form-urlencoded header.

This is my first Medium post ever, so let me know what you think or if you know of any shortcomings to this approach. So far, it has worked out really well for me!