Involving external parties in your Flow

Power Platform tools are great when you’re working in the context of you organization and when the people using your PowerApps implementation or Flow workflow are your colleagues under the same O365 tenant. 

Challenge

But what if you need to involve an external party in you business process to collect feedback, for example? Let’s say that at some point of a business process you need collect the following information from an external partner involved in the process but not being a member of your organization:

• Evaluation of the quality of the documentation produced during the process (scale 1-5)
• Free text feedback on the process

In addition you also need to be able to track that a specific questionnaire has indeed been answered. That implies that we need to be able to somehow embed an identifier in the questionnaire that we can later validate and match with the correct business process.

You can’t expose a PowerApps app to collect the information, because the external partner does not have access to your O365 tenant nor does he have appropriate license allocated.

You could use O365 Forms to collect anonymous feedback from external parties – but that’s just that: purely anonymous. You can’t identify the respondent in any way unless you configure authentication on, but that again requires the respondent to be a member of your O365 tenant. You can’t have e.g. URL parameters that you could use to track a specific request for feedback.

Solution

So let’s create a Flow that renders out a simple HTML form with the fields specified above and another Flow the handles the entered data when the respondent submits the form. The whole process is sketched below.

How does the user know where to browse initially? That’s entirely up to you 🙂 You could for example during you business process send a link in an e-mail to the external partner that will point to the HTTP trigger endpoint of Render form Flow.

My Render form Flow ended up to contain only two actions, a trigger and reponse. The trigger needs to read some sort of identifier from URL so that we can track the requests sent from our business process and match them correctly. We can use HTTP trigger’s relativePath parameter for that.

The second action is a HTTP Response action that returns the desired HTML form to the end user. You need to define text/html as content type – otherwise respondents browser will not render the HTML as a web page. You should also embed the _formId _identifier as a hidden field in the form so that you can later match the response with the correct business process. My simple test form looks like this:

I’ve included the formId received in URL as a hidden field on the form:

Then in our second Flow we can read the form_id parameter and use that to match the data to the correct business process instance.

Form element’s action point to the HTTP Request trigger of Receive data Flow.

My second Flow simply reads the posted data and does whatever is required with it.

My example Flow does not really do anything with the data – it simply reads the submitted form data from the HTTP POST body, creates a HTML table out of it and renders it to the user. In reality you would probably want to save the data to a database for example and send some notifications.

The HTTP Request trigger receives the submitted data in the form of a JSON array. The schema for the data is below.

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

After defining the schema you can iterate over the array to fetch all the form values you need (including the form ID from the hidden field).