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

• Solved: InvokerConnectionOverrideFailed – Power Platform Community (microsoft.com)

This is a little one, but sort of cool. I’m building a Power App which takes orders for shipment between stores. The person filling out the form can request a delivery date, but we want to give them a decent default. (It would be great if we could set minimum or maximum date in a date picker, but we can’t.)

Generally, something requested today can be delivered tomorrow, so we want a tomorrow which is smart about weekends, regardless what day of the week it is.

I came up with this little formula to set the DefaultDate for the form’s Requested Delivery Date date picker:

If(
     Weekday(Now()) = 6, // Friday
     Today() + 4,
     Weekday(Now()) = 7, // Saturday
     Today() + 3,
     Weekday(Now()) = 1, // Sunday
     Today() + 2,
     Today() + 1
 ) 

Like in Excel, the Weekday function returns the day’s number, where

Result	Meaning
1	Sunday
2	Monday
3	Tuesday
4	Wednesday
5	Thursday
6	Friday
7	Saturday

The net-net of the formula is:

If

  Today is Friday, the following Tuesday

Else

  Today is Saturday, the following Tuesday

Else

  Today is Sunday, the following Tuesday

Else

  Tomorrow

This won’t stop people from picking a bad date, but it will put them in the right place to start.

We will probably make this fancier to handle things like times after noon, but this is a good starting point for a smarter date picker.

It’s best practice from a security point of view to disable users from creating security groups or Microsoft 365 groups. Users can create security groups in Azure portals, API or PowerShell by default. The below setting will also prevent users from creating teams in Microsoft Teams as this will create a Microsoft 365 group.

In this post we will be creating a Power App and workflow to allow users to create teams on our terms. We will be letting users choose what type of Team they need and it will be provisioned. At the end I’ll be listing a few best practices regarding usability and security of this solution.

Prevent users from creating teams

The first step is preventing users from creating teams by switching the option to create groups to “No”. The user is able to create teams by default.

Switching the slider will show the following for users when trying to create a team

Create your Power App / Power Automate flow

You can create a Power App to you liking. I’ve just create a simple app with a few buttons.

The Power Automate flow is just as simple which will create a Team and add a user to this team.

Clicking on the button will create the default team

Best practices

Control and naming conventions

Adding an approval to the flow will give administrators control on which Teams are being created. Using the app you can use your own naming convention to know which teams have been created and filter based on them.

Service Account

Run / create the flow using a non-personal (service) account. This will make sure that the application will stop working when the account who created it is deleted.

Logic apps

This flow is created directly from the Power App where it’s also possible to use an Azure Logic App. This allows administrators additional monitoring. The behaviour of the logic app can be exported to a Log Analytics Workspace. An alert can also be created should the Logic App or an action in the Logic App fail.

The post Provision a Team in Microsoft Teams using Power Apps and Power Automate appeared first on Cloud Security | Office 365 | Azure | SharePoint.