Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierMarc D Anderson's Blog

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 the CSRRosterExport1.Run() instances with ExportEventRoster.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.

References

Creating Rules for Microsoft Lists – A Simple Alternative to Power Automate Flows

Somewhere between the classic Alerts functionality and Power Automate flows, we find the ability in Microsoft Lists to create rules for lists. Rules allow us to do some pretty basic – but VERY common things.

Creating a rule for a list is fairly straightforward. In the toolbar at the top of the list view, click on automate, and Create a rule.

There are only four options right now, but I expect this will expand. Microsoft is getting better at building what I think of as “bridging functionality”. Rather than the old days, where almost everything useful required a developer, there are now multiple options along a spectrum to accomplish many things.

The four options today are Notify someone when…

  1. A column changes
  2. A column value changes
  3. A new item is created
  4. An item is deleted

Note that #2 and #4 weren’t even possible not that long ago. We had to do all kinds of hocus-pocus for #2 and there simply wasn’t a “hook” for #4.

If you think about it, a huge number of SharePoint Designer workflows were built over the years JUST to send email notifications. This applies the 80/20 rule (one of my favorite rules – aka the Pareto Principle) to those use cases.

When you choose which rule you’d like to use – and I love how the graphics make it much easier to decide – you land on a screen where you just need to select a few values to set things up. If you’ve ever created a rule in Outlook to shuffle emails from specific sources into folders, you’ll recognize this type of logic.

The screen is also “list aware” – it knows which columns might make sense for each slot and what its possible values are. Here, I’m asking the list to notify me when the Category column is (equals) “(1) Category1”.

For the notification, all Person columns in the list are available.

As you can see, there’s little thinking involved: the columns are available in a dropdown when you need them.

Once you’ve set up a rule or rules, you can manage them from the same dropdown.

The ensuing screen shows you all the rules you have created, allowing you to delete them or just turn them off. The “Off” toggle is excellent to have when you’re loading content or making bulk metadata changes. You can stop the flood of notifications easily but equally easily turn the rule(s) back on.

Under the covers, this capability undoubtedly uses the web hooks for list items. This means the notifications will be fast and painless.

By the way, you may be wondering what those notifications look like. Truth is, they are nothing fancy. But they probably look better than 80% of the notifications you ever built in SharePoint Designer workflows over the years. This is another area where I expect the capability will expand, allowing some level of customization for the emails.

So the next time someone asks you to write a flow just to send an email when list items change, make sure to think about using rules instead. They will be amazed how fast you solve the problem.

❌
❌