Recently, our company noticed some changes in the Microsoft Power Automate HTTP Request Received Trigger. In the past, our company leveraged this is in a multitude of ways, mainly to integrate ERP applications with Common Data Model data and using custom connectors to upload image files to Sharepoint in order to store them, however, recently we found that HTTP trigger has changed in the types of data that it can receive.
One of the first PowerApps use cases our practice encountered was a custom application that would allow this client’s service providers the ability to enter order data from their mobile devices. The user would enter the services that were disbursed and then solicit the customer’s signature to indicate their approval of the order. Thus, one of the requirements for this project was to capture the customer’s signature and generate a custom invoice that would contain the customer’s name and signature, as our client often ran into issues with their customers disputing charges for services provided.
At the time, PowerApps’ PenInput’s image property returned an image in “blob” format, which, when sent to a Power Automate workflow for storage in Sharepoint would lead to an unusable file. After doing some research, we designed a custom connector that would take the image and send it as a properly formatted file to a flow with the HTTP Request trigger. The custom connector would an HTTP request formatted as form-data – the image would be sent in the body of the request, and other information about the image would be sent in the request’s query parameters. The custom connector worked great and was used in 5 or 6 projects subsequent to our initial deployment.
Fast forward to a recent use case we had which required the same signature capture IP that we had developed. Easy, I thought, all I’d have to do is set up the custom connector and related Power Automate workflow and this aspect of the project would be done. However, I immediately ran into an issue – when I tried to test the signature upload functionality in the application we were working on, I immediately received an error saying that Power Automate could not accept requests that were not in JSON format.
This presented multiple issues. From a budgetary standpoint, I hadn’t anticipated running into an issue with the tried and true methodology that we had used the previous 12 months. Even more pressing was the thought that perhaps that all of the deployed projects we had might not be working. Immediately, I checked all of our deployed projects to ensure that these have been working as necessary and found that they all were functioning as expected, and had properly uploaded images the same day my new custom connector had failed! My next step was twofold – I wanted to first test an existing connector in a sandbox environment as well as create an exact copy of the custom connector that would be hooked up to a brand-new Power Automate flow. What my test found was that the legacy flow and connector continued to work as expected, while the new flow had the trigger error I’d run into.
This meant that we needed to rethink our approach in this task. I spent some time trying editing the Custom Connector to reformat the request body into JSON format but was unable to get Power Automate to accept the request. After doing some digging, however, I identified a new approach. Fortunately, PowerApps had added a new function (JSON()) that would allow us to reformat the blob-formatted image file into a format that could be uploaded to Sharepoint. Leveraging this function with the second parameter set to the “IncludeBinaryData” enum allowed us to reformat the image and create a PowerApps triggered flow to send the file content (and other parameters) for upload to Sharepoint, removing the need for a custom connector. Essentially, we were able to eliminate the reliance on the custom connector by storing the reformatted file content in a variable, and then send it through flow, simplifying the process and giving us more visibility to any errors that PowerApps or Power Automate may encounter.
We learned quite a bit from this experience. Firstly, it underscores the importance of re-testing previous customizations when scoping a new project – just because something worked in the past doesn’t mean that it will work seamlessly today. In this case, Power Automate’s HTTP request trigger stopped accepting non-JSON formatted data in new flows, while older flows continued to function, but this lesson can apply to every aspect of development. Secondly, having to rework existing technology exposed us to the JSON() function which has a variety of functional use cases. Outside of the ability to properly format signatures or any other value entered in a Pen Input control, this function also allows us to format and export collection data which can offload asynchronous processes to Power Automate. Overall, what seemed like a major issue at first turned out to be good – it forced us to increase and stretch our knowledge of PowerApps and custom connectors, as well as reflect on our estimation process.
