Why?
It has been quite some while now since Microsoft announced that Power Automate Flows using premium functionalities, could run within the context of Power Apps. But it was only recently that I came across an enforcement notification from a Power Automate Flow: “This flow’s owner needs a premium license“.
The instructions to get a license and fix it are pretty clear… However in this case, we should consider this scheduled automated flow as “within the context of Power Apps“. For more details please see Frequently asked questions about Power Automate licensing – Power Platform | Microsoft Learn, but this meant that I could use the Power Apps Per User license or the Power Apps Per App license to run these standalone flows –> as long as they are within the context of the (premium licensed) Power App. To technically accomplish this, we need to associate the Flow to the Power App that premium licensed users are using 🔗.
What?
This blog post is on how to associate a Power Automate Flow to a (premium licensed) Power App and make it run “withing the context of Power Apps“.
How?
The most up-to-date instructions can be found here: PowerShell support – Associate in context flows to an app – Power Platform | Microsoft Learn.
1) First thing is to get the right information for the PowerShell action called Add-AdminFlowPowerAppContext.
The GUID of the environment which is referred to as the EnvironmentName parameter.
The GUID of the Power Automate Flow which is referred to as the FlowName parameter.
If your users are using a Model Driven App –> the logical (internal database) name of the Power App which is referred to as the AppName parameter.
If your users are using a Canvas App –> the GUID of the Power App which is also referred to as the same AppName parameter.
2) Then you can complete the Power Shell if you meet the pre-requisites regarding
– the minimum PowerShell version,
– the right PowerShell module(s)
– and of course the minimum permissions needed of the account you will be using to run the command.
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Force
Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber -ForceThen connect to the Power Platform with the Admin Account:
Add-PowerAppsAccountThen finally the execution of the command:
Add-AdminFlowPowerAppContext -EnvironmentName <String> -FlowName <String> -AppName <String>The end result of a succesful script run will be a Code 200 response:
Code : 200
Description : OK
Headers : {[Strict-Transport-Security, max-age=15724800; includeSubDomains], [x-ms-islandgateway, G
A000001K], [x-ms-request-id, westeurope:276c40a0-b7a3-4717-a8ff-b61839ef06a1], [x-ms-corr
elation-request-id, 276c40a0-b7a3-4717-a8ff-b61839ef06a1]...}
Error :
Errors :
Internal :Running the command again will give another Code 200 response so no direct way to check if the associations has been completed successfully or has been done before. However running the Remove-AdminFlowPowerAppContext action with the same parameters, on a flow that is not (longer) associated will return a Code 204 response giving us an indirect way to verify an association:
Code : 204
Description : No Content
Headers : {[Strict-Transport-Security, max-age=15724800; includeSubDomains], [x-ms-islandgateway, GA0000
01K], [x-ms-request-id, westeurope:9bc3417f-cd04-4e88-ba37-e62812c9e87e], [x-ms-correlation-re
quest-id, 9bc3417f-cd04-4e88-ba37-e62812c9e87e]...}
Error :
Errors :
Internal :I expect that Microsoft will create a nicer (graphical) user experience from within the details screen of a Power Automate Flow for this scenario. But until then –> this is the way to go 💪👍.
Hi, this will be an issue as we use service account to import the solution to UAT environment. Solution has app and flows. Here flow owner that will be service account needs to have premium app per user license whereas SA never going to use that APp . It is only used to import solution
Hi Rakesh in previous discussions there sometimes is a difference in what someone considers to be Service Accounts, so forgive me if I understand incorrect.
If you import Solutions (manually) into another environment, the Connection References of those Solutions are often created upon import. In your case this would be the SA who would never use that app.
If you have scheduled or automated Power Automate Flows, I would expect indeed that the SA would need a premium Per App pass at minimum because the actions of the Flow will run under the SA credentials. However Flows directly linked to the Power Apps will run under the user executing the Flow so no premium license needed then for the SA.
Especially if you are using multiple DTAP-environments, the business case for a Premium license on the SA should be easily reached right?
So sad news. I haven’t been prompted right now but it will definitely impact users and ‘service accounts’ used to host and run apps & standalone flows, related or not. Meaning we will also have to buy a power automate premium license for a svc account in order to simply run standalone flows, or link it with a ghost app to be compliant with this restriction… I’m also wondering if linking a flow with the app will behave like including the flow in the app through a button and ask users of the app to authenticate against the connectors used within the power automate workflow ?
Hi Matt,
That were also some of the questions I had when I first heard about the pending Microsoft enforcement…
What I do not understand in your comment is about the “ghost” app??
You either have stand alone Power Automate flows that are using premium connectors but there is no Power App –> then there is no premium Power App so this post is not relevant for this scenario because then you are already requiring premium (Power Automate) licensing to run these flows right? This enforcement has been there from the start.
…or you have flows within the context of an app that users with premium (Power App) licensing are using –> that is where this post will help. Linking the flow to the app is a back-end association for the Microsoft enforcement so it is applicable to Automated and Scheduled flows. Flows called from a button in a (Canvas) Power App are already associated as within the context of the app so this post is not relevant for that scenario.
Does this clarify?
Thanks for your reply. Let me explain more my thoughts about ghost apps.
Until now, we were able to fully use premium capabilities of Power automate workflows with only a powerapps per app license. Meaning we created some apps with related flows (ok, fine), but also sometimes standalone workflows using premium connectors. For example, a scheduled workflow to look at the office 365 message center and push it somewhere. This kind of workflow could use some premium actions (like http action or whatever) and would run nicely only with the powerapps per user license. Now, with this enforcement, this workflow would be disabled after 90days. So, imagine you can’t afford an additional license, you would create a “fake app” only to be linked with this workflow and benefit from the “within app context” capabilities. This is what I meant when talking about ghost apps.
I may be wrong as I never experimented this limitation but either the platform was too permissive until now allowing us to do premium in standalone flows with only a PowerApps per user license, or this change can really be impacting
Yes yes yes!
Exactly one of those scenario’s that were possible… but are not to be considered as “within the context of the (Power) app”.
Linking a flow to an app may be the only technical enforcement that is currently possible, but linking it does not mean that Microsoft will automatically consider it to be within the context. The main criteria that I often hear mentioned by the product team = the stand alone flow should touch (parts of) the same data as the premium licensed Power App. So you will probably have a premium licensed database (like SQL or Dataverse) and standalone flows touching any of the tables from the Power App, WILL be considered as within context. Still some room to abuse the concept but let’s have some more faith in mankind 😁