Upcoming Licensing enforcement in Power Automate explained

A few weeks ago I saw a message in the M365 Message Center regarding “Non-compliant” flows. Unfortunately, I can’t find the message any longer, but it was pretty concerning because it looked like a lot of flows could be turned off during the summer holiday season. Therefore I am making this attempt to explain the upcoming licensing enforcement in Power Automate.

This whole topic created some uncertainty and discussion between my colleagues, customers and other people within the community.

During the last couple of weeks, I had some discussions with both Microsoft and other people from the community. This whole approach of a non-technical post explaining licensing is something I usually don’t do. But in this case, I feel it still is a part of what I like to do, ALM. In addition, the information is very much spread out across different MS learning sites and therefore hard to understand. So I try to summarize it for you and explain it as well as I can.

As always everything I write is like this as of writing (2023-07-31) but could change at any time.

All I talk about in this blog post applies to all type of environments. This includes developer environments. In this case, it should not be a big problem since the user creating flows usually has a proper license.

Background

Microsoft will start with licensing enforcement in Power Automate. This means flows not meeting the requirements will be turned off. If you are unaware of this and you (or your admin/maker) don’t take any action this could lead to problems when the functionality currently in place is suddenly not working anymore.

Applies to

Let’s dive into which Power Automate flow it applies to, what Microsoft requires from a flow and what they will enforce.

What they basically say is that a flow needs to be licensed correctly. So far so good and understandable.

But what does “correctly” mean?

If the owner of a flow has a “proper” license everything is fine. A proper license could be one of the following (not exclusively):

• Dynamics 365 License
• Power Automate per User License

If one of the following (the list might not be complete) is the case you need an additional Power Automate per flow license for every flow:

• The owner has a Power Apps license
• The owner does not have a license any longer (for example had a license via a trial)
• The owner is not part of the organisation any longer
• The owner is a service Principal (or any non-interactive user)

Shortly after publishing this post I found out that Microsoft is retiring the Power Automate per Flow license. It will be replaced with the Power Automate Process Plan as of 2024-02-01 (read more).
Be aware that the Process Plan costs 150 USD where as the per-flow license costs 100 USD. But the per flow license has a minimum amount of licenses one has to purchase where as the process plan has not.

The last one is the one which concerned me the most. As you might know I “preach” a healthy ALM. One part of that is to use a Service principal to run the pipeline (and deployment). This means that all flows imported with the solution are owned by the used service principal. This would mean all flows in the downstream environments are subject to this enforcement and would need an additional license.

For most of our customers flows in the development environment will not be a problem since they are owned by developers/users. Problems arise when we deploy to Test or Prod using our pipeline.

Exclusions

Power Automate per flow licenses do cost currently 100 USD per flow and you need to buy at least 5 licenses. This can get quite expensive very fast in case we need additional licenses for every flow just because we follow a healthy ALM (as suggested by Microsoft)

Fortunately, there are certain criteria to exclude a flow, which would otherwise fall into one of the mentioned groups, from the enforcement of an additional license.

• Flows using first-party Dynamics apps
• Flows “talking” to Dynamics Entities
• Flows using the same data source as Apps
• Flows started/requested by Canvas Apps
• Flows “in-context” of an App (first-party, third-party or custom)

The mentioned groups are described in the docs of the Retention limits and Power App license capabilities.

For the first 4 groups, Microsoft should do the association to an app automatically. The last group is something you have to do yourself.

In-Context

The whole definition of what in-context of an app means is a bit vague. On the Power App license capabilities page Microsoft describes it as follows

Another definition I got from MS is

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.

Microsoft also sees flows for data cleansing as not in context.

Solution

Let’s see how we can fix the problem of flows not correctly covered by licenses and therefore in jeopardy of the upcoming License enforcement in Power Automate.

Find the flows in question

First of all, we have to find flows which need association.

Microsoft has created a PowerShell script which we can run against environments to find flows which aren’t licensed correctly. It is called “Get-AdminFlowAtRiskOfSuspension” and is part of the PowerShell module “Microsoft.PowerApps.Administration.PowerShell”. Unfortunately, it is not documented on the modules documentation, but on the FAQ page of Power Automate licenses.

Be aware that the result of this script could be different between different environments even though the same flows are installed. This is because the owner could differ which could include different licenses of the flow owner. Therefore flows might be in jeopardy in one environment but not in another.

Association

If you have identified a flow you have to associate it with an app.

This can be done either through the UI or with a PowerShell Script. There are some good community resources on how to use them. For example from Lewis or Alex.

An association is solution aware and will be deployed to downstream environments. A requirement is (afaik) that both the flow and app are in the same solution. Otherwise, the association might fail.

Be aware that the association will fail if the app and the flow do not use the same data source.

Microsoft will also check whether the App you associated the flow with is used. If they detect that the app isn’t used the flows will still be marked as not compliant and turned off after the grace period. This is to prevent you from creating a dummy app where you associate all the flows to come around the enforcement.

Timeframe

The last part I would like to talk about is the timeframe of this enforcement. As Microsoft Learn states on the Retention Limits page the whole process of enforcement should have started first of June. I got the information that MS has moved this to start on the first of August (so today). The docs haven’t been updated, unfortunately.

The first step in enforcement is that from the first of August, the owners of a flow, created before the first of August, which isn’t licensed correctly get notified. Owners do have 3 months to do any changes and fix the problem. When the flow isn’t correctly licensed after that time period it will be turned off.

Flows created after the first of August can’t be activated if they aren’t licensed correctly.

Microsoft mentioned to me that admins would have 5 months to do the fix. When this applies is a bit unclear to me. I would assume when the owner isn’t reachable the admin gets informed and then have 5 months to fix it.

Conclusion

The whole topic leaves some parts to interpretation since the documentation is (at least partly) vague. I hope MS will improve documentation around this. Hopefully also have all the information in one place.

But if you have all the information and got your head wrapped around it it is getting understandable and manageable.

I hope this helps and as always feel free to give me any feedback as well as ask questions.