On Power Automate Licenses and Automation Design

We have blogged about Power Automate and its capabilities before. It is a framework for process automation which can run both in the cloud via APIs as  well as on machines via RPA. It is part of Microsofts Power Platform and can therefore easily be integrated with Power Apps or be part of agentic AI when giving automation flows as tools to Copilot Studio agents. In this post we want to focus on licenses and automation design not in terms of "getting the job done" but optimizing automation with respect to the used licenses. The reason we feel like blogging about this topic is the reocurreing confusion about Power Automates licenses, which we encounter quite often. Most of our projects involving Power Automate start with the use case definition, i.e. "what is the problem we want to automate?". Next up is our part in finding a solution which may include some automation flows. The next obvious step is then, "how much will that cost?" and this is where things can get tricky.

Screenshot from Microsoft, taken in May 2025.

Recently we took over a project which was mostly implemented by someone else and we were tasked with adding some final details. There was a business process flow in which users can fill out information, i.e. interacting with dataverse tables and cloud storages as well as the sending of notification emails and gathering of approvals. Those interactions were all implemented as cloud flows using Power Automate and they were neatly organized such that, at the end of each stage in the business process flow, there was a cloud flow to be triggered. The triggers were all manual, i.e. the person filling out the information can press a button once they're done with their part. This worked well and made sense to both the developer as well as the client. That is until the question come up as to who is going to interact with the process.

You see, in order to manually trigger Power Automate flows including premium connectors (and yes, dataverse interactions are all premium) one must have a Power Automate Premium license. Obviously the person owning the flow has one, but what about the people "merely" interacting with it? Yes! They as well, basically everybody who wants to manually trigger a premium flow must have a premium license. Given the fact that about 30 or so people were supposed to work with the business process flow, the cost of doing that ballooned from 15$ / month (premium license for that one person who owns the flow) to about 450$ per month! This was a product breaking flaw which was only discovered a mere weeks before going in production.

The business process flow consists of a Power App through which users enter data into a data table (dataverse), a meta table that tracks the progress of each process, and a bunch of cloud flows, that gather approvals, update departments via emails and interact with data storages / databases.

Needless to say our "final detail adding" task was turned into something new. Once we understood the problem we first started looking into alternative license possibilities, like an app license or process license. A process license would have allowed for the users to interact with the flow without having premium licenses themselves, but since there were a few flows and each one would have needed its own 150$ / month process license, this approach would have been too expensive as well. The solution we came up with instead was an orchestrator flow. A cloud flow we developed new, which is automatically triggered by changes in a dataverse table. You see, every business process flow comes with a meta table, in which for each currently active process an entry exists that tracks in what stage that process currently is. Whenever a user is done filling out their information, instead of starting an automation, they would merely click on "next stage". Our orchestrator flow would then get triggered by that change in the stage meta table, figure out which flow was moved into what stage, and what flow must therefore be triggered. All the flows my predecessor has developed, were changed so that they can be triggered by this orchestrator flow instead, and so all the functionality was kept alive. While this was more work than we anticipated, we did succeed in turning a 450$ / month automation back into the 15$ one which is what the client had expected.

Example screenshot from a business process flow. This is the app view, that users see. Pressing the Next Stage button will under the hood make a change to the meta table, which triggers a cloudflow. The alternative is to have an explicit "Run Cloudflow" button, but that would require users to have premium licenses. 

Final thought: We wrote this post because of how involved we were with this project and because so far we hadn't blogged on this very vital aspect of the technology. From a developers perspective it is just a minor difference between triggering the flow via button vs. triggering it automatically from reacting to changes in a table. From the clients/users perspective this difference is even smaller, as all they see is either the "Run Flow" or "Next Stage" button. But the consequences on licenses and cost is immense!  When automating processes, we most often start by understanding the process, creating a flow chart of what we understood, having the client approve of our understanding and then start designing/implementing the flow. We strongly recommend having an ROI estimate as part of this initial project preparation, taking into account both the expected savings from the automation as well as the expected cost for running & maintaining it.