I’ve been trying to figure out the exact definition of what being “in app context” means for Power Automate flows, since that’s where it matters for license enforcement, but every time I seem to come close to having it all figured out, there is always something that does not quite add up.
Here is a good starting point:
https://learn.microsoft.com/en-us/power-platform/admin/power-automate-licensing/faqs
So, basically, the flow must use the same data sources for triggers or actions as the app. At which point we can now link that flow to the app in the maker portal, and it’ll be associated. And there is a special reference to the inactive apps… and I guess the idea is to stop people from creating dummy apps and associating flows to those apps.
This seems simple enough so far.
Also, it’s worth mentioning that “in app context” considerations matter mostly for the premium flows, since, ultimately, it’s a question of whether we can use Power Apps/D365 licenses when running the flows or whether we need to employ flow licenses (be it per flow licensing and power automate per user licensing).
For D365 licenses, there is a very similar statement here:
Also, nowhere above it’s mentioned that “in app context” flow has to use the same tables as the app. It’s actually worded differently here:
https://learn.microsoft.com/en-us/power-platform/admin/power-automate-licensing/faqs
It does refer to the fact that you’d be using cases above, but it’s not a direct reference. In the bullet items, it’s just “Dataverse trigger or action”.
Case closed? If there is an app that’s using Dataverse, I can license any flow in the same environment through the Power App license (or D365) as long as that flow is also using Dataverse?
It seems so based on the above, but then there is, also, this:
https://learn.microsoft.com/en-us/power-platform/admin/power-automate-licensing/faqs
Item #3 throws a wrench into all those considerations above, since it completely ignores automated and scheduled flows.
Item #4 is talking about the flow having to interact with Dynamics entities, which turns everything on its head, since, it seems, it’s not sufficient to just have that flow using Dataverse – it has to interact with D365 entities, and, by extension, I’d assume the same logic should be applied to custom Power Apps.
In other words, if I were looking at this and were trying to come up with the safest interpretation (in the sense that, if and when more enforcement is implemented, my flows would still be working), I’d probably use the logic below (and I’m mostly looking at it from the Dataverse perspective by the way):
- Whether it’s a D365 or a Power Apps license, my flow has to be associated to the app through the new association mechanism available in the maker portal (or through PowerShell)
- I should only be associating those flows which are actually using the same tables which are being used in the apps to which my flow is going to be associated. Keeping in mind that, for this particular item, D365 licensing only covers D365 application tables
- When selecting an app, it has to be an actively used app, not a dormant one
***This is ignoring the fact that item 3 on the last screenshot above is mentioning that a flow has to be triggered by the app. Hopefully, that’s not how it is.***
Which means, for instance, that, if I start adding custom tables to my D365 environment, I might not want to use D365 licensing for the flows which are only working with those tables (if I wanted that flow to be license-compliant).
With the Power App licensing, I may also need to ensure that all my custom tables are actually added to the app, not only to the solution.
There is also a question of what happens to the flows which are owned by a service principal (as in, by an application account).
There is a reference to it here:
Which, by extension, will probably apply to the flows running on the Power Apps owner plan like this:
Premium service principal flows that are outside of the Power App context will each need a per flow license.
In general, I think that’s “acceptable”, though I am not sure what to make of having to use D365 tables in the D365-licensed flows. We would often be adding custom tables, so do we need to obtain additional licenses?
And then there is one final note that turns everything on its head (although, I thought it just happened above) and my hopefully reasonable constructs above just don’t hold anymore:
So… There is more to it? It’s not sufficient for a flow to be in the same environment as the app, to be using the same tables, and to be associated to it? Have been trying to figure it out for a while, but I seem to be running in circles 😕