Monthly Archives: February 2022

Are your flows “within context”?

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.

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)

Flow execution “within context” of the app

If you look at the Power Apps licensing guide, you will see that flow execution is, usually, permitted within app context:


That same wording applies to pretty much all licence types, including Dynamics 365. And there is a corresponding note in the Power Apps Licensing FAQs:


Question, though. How do you read this?

For example, if you have a model-driven application, are you allowed to use a flow to read data from, for instance, Azure SQL and write it to Microsoft Dataverse?

It’s a different data source, after all, and we are supposed to use the same triggers or actions as the Power Apps application – in case with a model-driven application, the only actual datasource it would be “using” is Microsoft Dataverse, and only specific tables for that matter.

Should Sharepoint / Outlook / Word be included? Technically, model-driven app is not using those in the “Power Automate” datasource sense.

Or, when thinking of the Canvas Apps, can users given per app plan for a specific app use app’s data source in combination with Power BI Connector?

(Updated on Feb 2) it seems I got the answer here: