Power Automate Licensing for in-context flows
Just when I thought my recent encounter with the upcoming licensing changes was dramatic enough, it turned out there is more to it.
The text explores the nuances of Power Automate Licensing for in-context flows. The author references their recent encounter with upcoming licensing changes, suggesting there may be more to the issue than initially assumed. The text is tailored towards those with existing projects using multiple flows, apps, etc., warning of potential hurdles that may entail loss of sleep. Simultaneously, it addresses those just embarking on a new project, admonishing that additional planning and work might be warranted.
The upcoming changes in licensing might be more dramatic than you expected, especially if you are using multiple flows, apps, etc in your project.
Key Takeaways:
- A previously vague concept of a "flow being in context of an app" is becoming more specific.
- There will soon be a requirement to associate your flows with the apps.
- If you've been licensing your flows through Power Apps licenses, those flows need to be in the context of an app.
- Flows not associated to an app will not be "in context", regardless of how they've been setup.
- Flows that aren't in the context and licensed through a Power Apps license might need a new license.
- An association between a flow and an app might be created, even if the flow is not supposed to be "in the context". But proceed with caution.
- An association cannot be created if your flow isn't using at least one of the datasources that the associated app is using.
Basically, it seems that a relatively vague concept of a “flow being in context of an app” is going to become very specific (soon?), and we will need to start associating our flows to the apps.There is a bunch of examples there which will tell you what can be considered an associated flow and what cannot be considered an associated flow, but, aside from that, we will need to literally associate flows to apps:Although, as of writing this blog post, I can’t, really, find “Associated Apps” area in the Power Automate / Power Apps portals when looking at the flows.
When the flow can be deleted, since it has no purpose anylonger, when the app gets deleted, it is “in-context” of that app.
For me, that is a bit more clear than the other definitions. Still the “in-context” has a lot of space for interpretation.
- Install the required PowerShell module: Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -RequiredVersion 2.0.156
- Find your environment ID and use it to run the following command: Get-AdminFlowAtRiskOfSuspension -EnvironmentName <ENV ID> -ApiVersion ‘2016-11-01’
- Check the list of flows that might be at risk of suspension.
If your environment contains any flows, you should consider starting to add the necessary associations. For now, the associations require a PowerShell command: Add-AdminFlowPowerAppContext -EnvironmentName <String> -FlowName <String> -AppName <String>
The changes in Power Automate licensing might seem daunting, but being proactive and adapting to these changes can ensure your environment's continuity and compliance.
Read the full article Power Automate Licensing for in-context flows
Per User Plan and Per Flow Plan
Power Automate license plans work in two ways: per user and per flow.
Per User Plan: This plan covers all flows a single user creates or executes. If the user has multiple plans (like a Microsoft 365 and a Dynamics 365 plan), the flow uses the request limits from both plans. Microsoft recommends this for personal automation and broad adoption of an automation culture in organizations.
Per Flow Plan: This plan is intended for enterprise process automation and has the highest limits. It is ideal for situations where a flow provides value to a team or the whole organization, using premium connectors and serving many guest users. Unlike per user plans, this allows organizations to pay for licenses based on the number of flows used.
Licensing requirements for premium features depend on the value derived from the flow. If an automated or scheduled flow uses a premium connector, only the owner needs a premium license. However, if an instant flow (like a button or hybrid trigger) uses premium connectors, each user requires a premium license or the flow needs a per flow license.
User-level licenses, including per user, Microsoft 365, and Dynamics 365, are tenant-level licenses, meaning users can use the flow in all environments without needing to buy separate licenses. On the other hand, each flow instance in a different environment requires a separate per flow license.
Guest users also require Power Automate licenses assigned either by the tenant hosting the flow or their home tenant. Licenses included with Office, Power Automate per user, per user with attended RPA, Power Apps per user, and Dynamics 365 user plans are recognized across tenants in guest scenarios within the same Azure cloud.
If the owner of a flow leaves an organization or loses a premium license, the flow can be maintained by changing the owner, assigning a per flow license, or exporting and importing the flow under a new owner. If no action is taken in 14 days, the flow's performance will be downgraded and eventually turned off.
Power Automate Licensing
Power Automate is a powerful tool for automating processes, but it comes with certain licensing restrictions. For in-context flows, Microsoft is introducing new licensing rules that will affect how many flows can be associated with an app. In order to understand the new rules, it is important to understand what is meant by an in-context flow. In-context flows are flows that are associated with an app and are triggered when a user interacts with the app. Examples of this type of flow include flows triggered by user actions such as clicking a button, making a selection, or entering data. Additionally, flows triggered by a timer, scheduling, or data-driven events are also considered in-context flows.
In order to ensure compliance with the new licensing rules, it is important to keep track of the number of in-context flows associated with an app. This can be done by referencing the Frequently Asked Questions (FAQs) about Power Automate licensing. The FAQs cover topics such as the number of flows associated with an app, the types of flows that are considered in-context, and the licensing requirements for each type of flow.
It is also important to be aware of the various ways in which an in-context flow can be triggered. For example, an in-context flow can be triggered by a user action or by data-driven events. Additionally, flows can be triggered by manual triggers, scheduled triggers, or timer triggers. Understanding how each of these triggers works and ensuring that the flow is properly associated with the app can help to ensure compliance with the new Power Automate licensing rules.
In summary, it is important to be aware of the new Power Automate licensing rules for in-context flows. Understanding what is meant by an in-context flow, as well as the various ways in which an in-context flow can be triggered, can help to ensure compliance with the new licensing rules. Additionally, referencing the FAQs about Power Automate licensing can help to ensure that the number of in-context flows associated with an app are within the limits set by Microsoft.
Keywords
Power Automate Licensing, Flow Context, Power Platform, Power Automate Licensing FAQs, Power Automate Limits, Power Automate Associated Flows