Fixing the `InvokerConnectionOverrideFailed` Error When a Power App Calls a Power Automate Flo
One of the cool things you can do from a canvas Power App is call a Power Automate flow. This is a great way to do something simple – like sending an email – or many more complex things you might want to trigger from the Power App. Many have written about how to implement these sorts of things, so I won’t cover that ground here.
Once you’ve got it set up and time goes by, your users may start to see an error message similar to this when they take the action to trigger the flow in the Power App. It might be a button click, changing a number in a field – it can really be anything where you can connect to an event in the Power App.
That’s:
{"code": "InvokerConnectionOverrideFailed", "message": "Failed to parse invoker connections from trigger 'manual' outputs. Exception: Could not find any valid connection for connection reference name 'shared_office365_1' in APIM tokens header."}
The contents of the error you see may be a little bit different, but every report I saw mentioned InvokerConnectionOverrideFailed
.
This is a post which shouldn’t need to exist, in my opinion. Once we have the connection between the Power App and the Power Automate flow, it should just work going forward. But after some indeterminate amount of time has passed, you may start to see the error above. The two tools somehow lose their connection.
We had this happen at a client recently, so I went off to the InterWebs to see if I could find an answer. There are multiple posts about it with multiple answers. I’ll summarize the one I found that worked for me here.
In my particular case, the Power App enables event signups. Each event has one or more available time slots with a maximum number of registrations. When the event is coming up, the admins may need to provide a roster for each time slot to the event organizers, who are often outside the organization. We have a button in the Power App visible only to the admins which triggers a flow. That flow creates an export of a set of the specific event’s signup data in an Excel spreadsheet and the admin is notified via an email with a link to the Excel file when it is complete.
Here’s the sequence that solved the issue for me:
- Export the existing flow. The old flow was named
CSRRosterExport1
. - Import the exported flow’s ZIP file with a new name, but everything else exactly the same. The new flow’s name was
ExportEventRoster
. - In the Power App, add the newly instantiated flow as a connection. To do this, from the top menu, choose Action/ Power Automate and specify the Flow you’d like to call.
- Replace all calls to the old flow with calls to the new flow. In this case, it was the
onSelect
events for two buttons, each of which passed slightly different parameters to the flow. It amounted to changing theCSRRosterExport1.Run()
instances withExportEventRoster
.Run().
Now that I know the fix, it probably takes about 10 mins – at most. When our users see the error message, we can easily Band-Aid the problem. Of course, this issuE shouldn’t happen in the first place, so let’s hope Microsoft fixes it before we ever see the error again.
Today I experienced the same error with running a flow in a PowerApp form. The form is SharePoint list integrated.
My fix was a little different. I located the button that was triggering the flow and copied the run command so i don’t lose it. Then i went to datsources on the left and removed that specific connection from PowerApp. Saved. Published.
Went back to SharePoint to confirm button doesn’t work.
Then back into PowerApp and back to the same button, re-added the PowerAutomate Action and pasted back the original run command. Saved. Published. Tested.
It works!
Thanks, Andy! This worked for me also!
Thank you! Worked for me too!
I just refereshed the Flow in Powerapps and it fixed it.
Super helpful, thank you. Why would this solution work? Why does this fix the problem?
TBH, @Noah, no idea. Sometimes workarounds work and we move on.
Fair enough and thanks, worked for me as well, but shouldn’t we hold MS to a higher standard? I’ve been having so many stupid problems with Power Apps lately. Issues like same code working differently from one day to another, one user to another. Seeing the results of a bug but being unable to reproduce it… you know, the annoying stuff that we can’t fix because we can’t see it. If I had any say in it, I would tell them to lay off the new features until they fixed the existing ones, and maybe take a deep dive into their backlog. For example, they have a bug where versions fail after 100 for years now, no fix, no nothing. Anyway, rant over, thanks for sharing the fix.
I totally agree. We all spend far too much of our days coming up with workarounds. The best thing we can do is report the issues and hope someone pays attention. Sadly, they usually do not.
It’s Mar 16 2023 today and the error still exists. Sigh
This makes us look bad in front of our clients. Blame MS is all I could say to them.
Hi Marc and thanks for this hint, which was really helpful for me :-)
I had recently the same observation in a flow … and exporting and creating a “new” reimported flow (with all the necessary confirmations of all connections) resolved the problem.
I wonder if the problem was possibly related to the fact that I had replaced the flow trigger during development. The “InvokerConnectionOverrideFailed” error occured exactly in that moment, when I added an action, which needed a new connection (in my case to Teams; I had alread connections to SPO, Outlook 365 and Yammer). I believe I’ve read recently something about “be careful with trigger exchange during development, because this could cause connection issues”.
Just an idea …
Regards, Lübbe
Hi — coming to you from July 2024, so the problem is still with us. Thanks MSFT!!
My solution was much simpler: just refresh the connection from PowerApps to the Flow (click the ellipsis next to the offending flow and select Refresh).
I have a hidden page in the app with a button to run just this flow because it’s happened so many times now, I’ve set up a workaround!