Although flows that are bundled in a solution can call each other natively, flows that have a SharePoint manual trigger are not allowed to be included in a Power Automate solution. That means I have to create my flow with the SharePoint trigger outside the solution, and then call the child flow (inside the solution) using an HTTP call. My question is: what's the best way to secure that call?
I've tried using the API Management service in Azure to wrap the URL, but I'm struggling because all the examples are for calling Logic Apps and are about 5 degrees away from what I'm trying to do, which is to simply add security to my HTTP call. Can anyone provide any guidance? (Am I missing something really simple?)
Solved! Go to Solution.
Thanks. At first I was trying to use API management but then realized all I'm doing is obfuscating the call, but that doesn't really secure things from the receiving end. I didn't really want logic inside my flow having to check any values, because by then, I've used up one of my flow runs. I like the idea of passing in a token into the trigger, and then having a trigger condition. That way, if someone attempted some sort of denial of service attack, it's Microsoft's problem and not mine, since it wouldn't count toward my flow runs and my code wouldn't execute.
Does securing the inputs and outputs do anything more than hide those inputs and outputs from the UI? I'm not so worried about people internally having access to the right stuff, but more hackers getting a hold of the flow's HTTP trigger URL and firing it.
The first Microsoft-sponsored Power Platform Conference is coming in September. 100+ speakers, 150+ sessions, and what's new and next for Power Platform.
Announcing a new way to share your feedback with the Power Automate Team.
Learn to digitize and optimize business processes and connect all your applications to share data in real time.
Join Priya Kodukula and the licensing team, super users and MVPs to find answers to your questions on Power Automate licensing.