Power Automate, flows and licensing traps

Power Automate, flows and licensing traps

Power Automate is a tool for building flows that automate work: something happens, the tool reacts and runs a series of steps. A leave request lands in a form, the flow sends it to a manager, and after approval it adds a row to a sheet and notifies human resources.

The biggest problem with this tool is not building flows. It is licensing, which has two axes, several thresholds, and one boundary where cost jumps several fold. So we start there, since whether your idea pays off at all follows from it.

Standard and premium connectors

This is the line where the entire difference in the bill happens.

Standard connectors cover Microsoft's services: mail, calendar, documents, spreadsheets, lists, and chat. They come with the licence bundled into the office suite that most companies already hold.

The line does not fall where intuition suggests, though, and that is the first thing to check at source. Connectors for many popular services outside Microsoft are standard too: Google Drive, Google Sheets, Google Calendar, Dropbox, Slack, Trello, Asana, GitHub, YouTube, Twilio, and RSS feeds. A company moving files between Google Drive and a list in the documents tool stays inside the licence it already holds.

Premium connectors are databases, the platform's own data store included, cloud services, large sales and human resources systems such as Salesforce, some marketing services such as MailChimp, and calls to your own interfaces through an ordinary network request. They require a separate licence. The practical rule therefore reads differently from the one usually repeated: premium means databases, enterprise class systems, and your own interfaces rather than simply everything outside Microsoft. You check a single connector's status in its documentation entry, on the Power Automate row.

The consequence is direct and surprises most often. A flow reading a list in the documents tool and sending a message fits within what you have. That same flow extended by one database query or one call to your own interface crosses the boundary and requires a licence for everybody who runs it.

The practical advice: before building, check the step list against that boundary. Redesigning early to stay within standard connectors is often cheaper than licences for a hundred people.

Two licensing axes

Worth understanding the difference, since choosing the right axis can change the bill several dozen fold.

A per user licence lets that person run an unlimited number of flows, premium connectors included. You pay for every person who uses flows.

A per process licence works the other way: you licence a particular flow, and any number of people in the organisation may use it. That is the right pick for a company process used by many employees but rarely.

An example makes the difference clear. A flow handling leave requests, used by three hundred people a few times a year, means three hundred licences under per user. Under per process it means one.

The reverse holds for a team of ten building and running a dozen different flows daily. There per user licences cost less than a dozen per process licences.

A third axis concerns unattended desktop automation, meaning the tool clicking through an old application's interface. That is a separate licence and a separate bill, and when automating somebody else's software it pays to check their terms too, since some vendors require a separate licence for automated access.

When this is the right choice

Three conditions under which this tool clearly beats its competitors.

The first: the company works inside Microsoft's ecosystem. Integration with mail, documents, lists, and chat works with no authentication to configure, since identity is shared. That is a saving invisible until you try the same with an outside tool.

The second: flows get built by somebody other than the engineering team. The graphical interface lets a person from operations assemble automation without writing code, and that is a real change in an organisation's pace.

The third: data cannot leave the company's infrastructure. A flow running inside the tenancy sends no content to an outside vendor, which for human resources or financial documents is often a requirement rather than a preference.

Outside those conditions the advantage melts. A team working on other tools gains another vendor to handle, and a developer automating something for themselves usually writes a script faster.

Triggers and batch processing

Worth understanding how a flow starts, since that decides latency and the bill more than the step count does.

An event trigger reacts to something that happened: a row appeared, a message arrived, somebody submitted a form. That is the right variant in most cases, since the flow starts when it is needed.

A polling trigger checks a source at set intervals and starts the flow when something changed. It looks similar and differs in two ways: latency on the order of the polling interval, and consuming the execution allowance even when nothing changed.

That second property surprises when costing things out. A flow polling every five minutes runs close to three hundred times a day regardless of whether anything happened. Across several such flows the allowance drains faster than the number of handled cases suggests.

Processing many items at once is a separate matter. A step iterating a list runs the inner steps for every element, so a two hundred item list with three inner steps is six hundred operations. On larger sets it pays to enable parallel execution and limit how many items a single run fetches, since otherwise the flow exceeds its time limit.

The practical rule: if a flow works on more than a hundred items at once, redesign it to fetch them in batches and record where it stopped. That is work nobody wants to do and cheaper than explaining a process interrupted halfway.

Approvals and processes involving people

This is the use where the tool faces the least competition, so it deserves separate treatment.

An approval step sends a request to a named person and suspends the flow until an answer arrives. The answer comes from chat, mail, or a mobile application, and the flow resumes where it stopped.

The value's core is that waiting costs nothing and carries no practical time limit. A request waiting a week for a manager consumes no resources, while in a self built implementation it would require durable state and a resumption mechanism.

Several things deserve deliberate design. A substitute during absence, since a request waiting on somebody on holiday stalls. A reminder after a set period, since without one the process goes quiet. And recording the decision along with its justification, since the question of who approved it and when always arrives, only six months later.

Distinguish approval from notification too. A step sending a message and moving on is a notification, and a flow designed as though somebody read and acted on it is a mistake that surfaces on the first urgent case.

Power Automate against the alternatives

The first row wins on identity and permissions rather than capability. A flow reaching a particular employee's documents runs in their context, with their permissions, with nothing to configure. Reproducing that with an outside tool means configuring access and usually granting broader permissions than needed.

The second row deserves consideration when you want flows to be code. A definition kept in a repository, passing review and deploying like the rest of the system, is a different way of working from clicking in an interface, and with a technical team it is often better.

The third and fourth rows win on the catalogue of integrations with services outside Microsoft's world. If your process touches five external tools, they will be simpler.

The tool's limits

Worth listing honestly where this stops working well, since the vendor's material does not show it.

Complexity has a hard ceiling here. A flow with five steps is legible; with twenty five it becomes opaque; and with branches and nested loops it turns into something nobody but its author understands. The tools we take for granted with code are absent: splitting into functions, searching by name, meaningful version comparison.

Version control is simplified. A flow carries history, but comparing two versions does not look like reviewing code changes, and restoring a previous one is often the only way to undo a mistake.

Testing happens by running. There is no environment where a flow gets exercised without touching real data, so parallel environments get built, which doubles the maintenance work.

Performance carries limits. The number of requests per day, the duration of a single run, and connector call frequency are capped, and processing thousands of records requires working around that by splitting the work into batches.

What happens once those limits are crossed deserves knowing in advance, because intuition misleads here. The flow does not stop with an error, it slows down: the platform throttles the execution rate. The allowance is counted over a rolling twenty four hour window and attached to a particular person or a particular flow, so one process that ate its share does not slow the others. There are two ways out: buying capacity add-ons, each of which raises the allowance by another fifty thousand requests per day, or moving the environment onto pay as you go billing.

The practical conclusion: this is a tool for processes rather than for data processing. A flow approving a request, yes. A flow recomputing a hundred thousand rows, no.

Building flows in practice

A few things save trouble over longer maintenance.

Name steps descriptively. Defaults like "Apply to each 3" make a flow from six months ago illegible even to its author. A name stating what the step does costs a second and pays back on the first failure.

Handle errors explicitly. By default a flow stops at the first failure and notifies its author, which for a company process means the matter stalls while one person knows about it. A step handling failure and notifying the right mailbox changes that.

Extract repeated fragments into separate flows called from others. That is the equivalent of a function and the only mechanism limiting a single flow's growth.

Assign an owner. A flow built by somebody who left the company and running under their account stops working the day that account is disabled. Service accounts or shared ownership settle that in advance.

The last item is documentation outside the tool. One sentence stating what the flow does and why it exists, recorded where the team looks, is worth more than twenty well named steps.

Common mistakes

The first is building a flow without checking whether any step requires a premium connector. Discovering that after finishing means either a redesign or licences for every user.

The second is choosing per user licensing for a process serving many employees rarely. A per process licence is then several dozen times cheaper.

The third is building one enormous flow instead of several calling each other. That produces a construction nobody but its author understands and which cannot sensibly be tested.

The fourth is running a flow under a person's account rather than a service account. That person leaving stops the process with no warning.

The fifth is no explicit error handling. The process stalls while the information reaches only the flow's author.

The sixth is using this for processing large data sets. Execution count and duration limits are hard here, and working around them by batching turns a simple task into a complicated construction.

FAQ

Is Power Automate free?

The basic capabilities come with Microsoft's office suite that most companies already hold, and cover standard connectors, which reach beyond Microsoft's own services too. A paid licence becomes necessary only for premium connectors: databases, enterprise class systems, and calls to your own interfaces. A thirty day trial also exists, along with a free developer plan intended for learning.

How do per user and per process licences differ?

In scope. A per user licence lets one person run any flows. A per process licence covers one particular flow that any number of people may use. For a company process used rarely by many employees the second option is often several dozen times cheaper.

Which connectors are premium?

Databases, the platform's own data store included, cloud services, large sales and human resources systems, and calls to your own interfaces through an ordinary network request. That last one surprises most often, since calling your own server does not intuitively look like an advanced feature. The reverse intuition misleads as well: connectors for Google Drive, Dropbox, Slack, Trello, and GitHub are standard even though those services sit outside Microsoft. Check a particular connector's status in its documentation entry.

Does it suit data processing?

Poorly. Limits on execution count, run duration, and call frequency mean processing thousands of records requires batching and working around restrictions. This is a tool for processes with approval steps rather than for computation.

How does it differ from n8n or Make?

In ecosystem embedding. A flow runs in the context of an employee's identity, with their permissions, with no access to configure. n8n offers control and self hosting in exchange, and Make a wider catalogue of integrations with services outside Microsoft's world.

The licensing terms are described in the vendor documentation, and plans on the pricing page.