Recently, we’ve been prototyping a solution which would be using Form.IO to collect web forms data, so we needed a way to somehow store submitted requests in Dynamics.
So what we came up with looked more or less like this:
Form.IO offers different types of actions, and one of those allows forwarding submitted data to a url in json format. That’s exactly how we can hook up Forms.IO to the Microsoft flow in the scenario above.
However, rather than walking you through the details on how “HTTP Request is received” trigger works in the Flows, I’ll provide a link to this other blog post by Serge Luca here:
That blog post also covers something else – specifically, it explains how to protect this kind of Flow through the Azure API Management. That came up as a question from the architecture/security folks almost right away once they’ve looked at the implementation above.
IP access restriction policy (which is described in the post above) seems to be most useful in this scenario, although, at the moment we are not sure we can use it with Form.IO since we would need to know the IP addresses Form.IO is using.
Still, basic authentication is supported on the API management side and on the Form.IO side. Also, we might add a policy for a custom HTTP header…
Other than that, the flow above is relatively straightforward. Of course Forms.IO can accept file attachments (and, in our case, we used Azure Blob storage to save those attachments), so, at least half of the actions in that Flow are really dealing with creating sharepoint document locations for the newly submitted case records. That part, is, basically, a replica of the flow described in the post below:
Except that we don’t need to create custom folders structure this time – we just need to create a folder per case in Sharepoint, then upload submitted files to that folder through the Sharepoint connector.