Yesterday, I posted a question asking what does it mean for a flow to be “within context” of the licensed application. Based on what I was able to figure out eventually, the technical answer might be somewhat different from what we could be assuming.
Note: you may want to confirm licensing with Microsoft whenever you have a question. What I am posting in my blog on this topic is just my opinion influenced by the reading / discussions I might have had. Some of those may have been with the product team, but, just to clarify, it’s the information in the licensing guides / docs we can safely reference when it comes to the licensing. Everything else falls into the “opinion” category.
In the FAQs, you’ll see this note (as of Feb 2):
However, flows will need to run within the context of the Power Apps application, which refers to using the same data sources for triggers or actions as the Power Apps application.
https://docs.microsoft.com/en-us/power-platform/admin/powerapps-flow-licensing-faq
So, for a flow to be “within context”, it has to be using the same data sources for triggers or actions, and, it seems, here is how we should be reading the note above when it comes to the model-driven applications, for example:
- When looking at the application, see which tables it’s using in Microsoft Dataverse
- For a flow to be within context of that app, the flow has to have triggers and/or actions which are using the same tables
- Such a flow, then, can still use non-Dataverse connectors if it needs to connect to other data sources, too
Where does it matter?
If you went with the “spirit” of being “within context”, you might think that a flow picking Dataverse data from the Service Bus and sending it somewhere else might be “within context”. But, since it would not be using Dataverse connector (and, hence, would not be using any of the application tables directly) in this scenario, it actually would not be “within context”, at least not technically.
Another example: maybe there is a manually triggered flow that’s using a Power BI connector to generate a paginated report and to send it by email. That report would be connecting to Dataverse and would be using application tables, but the flow itself would not. So, technically, such a flow would not be within context.
Or here is another example: if you had a scheduled flow that were querying application data from Microsoft Dataverse , processing that data, and sending an email, it would be fine. But, if you moved that processing into an Azure Function, and, instead of calling Dataverse from your flow directly, you’d started calling that Azure Function, the flow would not be “within app context” anymore. You may have optimized things, but the flow would need to be licensed differently now.
Well, hope this adds some clarity (even if this complicates licensing a little more)