A Power Automate flow is an automation that starts with a trigger and then runs one or more actions, and Microsoft documents the minimum for a cloud flow as one trigger plus one action. Most guides still describe five flow types. Microsoft’s own flow types page, updated in November 2025, documents three. This guide covers what a flow really is, what starts one and what stops one running.
Table of Contents
What is a Power Automate flow?
A Power Automate flow is a saved automation made of one trigger and a sequence of actions. The trigger decides when it runs. The actions decide what it does. Everything else in Power Automate, the connectors, the conditions, the loops and the error handling, exists to serve those two parts.
A flow has one trigger, not two. It does not have a second starting point. One trigger, one list of actions. That matters more than it sounds, because more often than not, a flow handed to us as broken is not broken in the actions at all. It is broken at the trigger. The flow is fine. It just never starts, or it starts far more often than anyone intended.
How often a trigger fires depends on how much process a business runs, and Australian organisations run a lot of it. The Australian Institute of Company Directors and Mandala Partners put the cost of complying with Commonwealth regulation at $160 billion a year, in research published in November 2025, up from $65 billion in 2013. That measures regulatory cost rather than automation, but it is a fair proxy for how much process there is to run.
If you are working out which processes are worth automating at all, start with our guide to business process automation and come back here for the mechanics.
What is the difference between a trigger and an action?
A trigger is the event that starts a flow. An action is a step the flow performs once it has started. A cloud flow carries one trigger and up to 500 actions. Microsoft’s documented minimum to save one at all is a single trigger plus a single action.
Microsoft documents the distinction directly: “A trigger is an event that starts a cloud flow. It defines the conditions under which your flow runs.” Actions are “the events you want the flow to do after the trigger event takes place.”
The part almost nobody explains is where the filtering goes. Most people trigger on every new item, then use a condition action to decide whether to carry on. That works and it is wasteful, because the flow starts and burns action runs every time regardless. Put the same test in the trigger condition and the flow does not start when the test fails. On a busy SharePoint list that is thousands of pointless runs a month, each one spending actions and filling the run history you will need when something does go wrong.
What types of flows does Power Automate actually have?
Power Automate has three flow types, not five. Microsoft’s flow types page, last updated in November 2025, documents cloud flows, desktop flows and generative actions, the last of which is still in preview. Automated, instant and scheduled sit underneath cloud flows. They are ways a cloud flow starts, not types of flow in their own right.
The familiar list of five comes from an older shape of the product and it is still repeated across most guides, including an earlier version of this page. Microsoft’s flow types page states it plainly: “Power Automate provides three types of flows to meet different automation needs.” Microsoft’s own get-started page does still call automated, instant and scheduled “three cloud flow types”, so the word type is doing two jobs across Microsoft’s documentation. Business process flows are a different thing again and are not listed on the flow types page at all.
Here is how the current taxonomy sits, and what each part is for.
| Flow type | Cloud flow start mode | What starts it | Typical use |
|---|---|---|---|
| Cloud flow | Automated | An event, such as an email arriving or a list item being created | Work that should happen the moment something occurs |
| Cloud flow | Instant | A person selecting a button, in Teams, on mobile or inside a Power App | Jobs a person decides to run |
| Cloud flow | Scheduled | A recurrence you set | Nightly consolidations, weekly reminders, periodic housekeeping |
| Desktop flow | n/a | A person, or a cloud flow calling it | Legacy software with no connector and no API |
| Generative actions (preview) | n/a | Added inside a cloud flow, so the flow’s trigger starts it | Preview only, not production work yet |
Automated cloud flows are the workhorse. Microsoft describes one as an automation “triggered by an event such as the arrival of an email from a specific person”. A manufacturing client of ours in Darwin runs two of them, one for quotes and one for projects. A project emailed into a nominated Teams channel triggers a flow that reads the project name, square metres and due date, sanitises the folder name for SharePoint, builds the folder structure across every site and raises the Planner task. The project setup automation case study records the outcome as “100% Identical folder structure, every site, every job” with “Zero Missed tasks, a Planner task raised on every job”.
Instant cloud flows start when someone chooses to run them, which Microsoft defines as “Start an automation with the selection of a button”. That button can sit in Teams, on a phone or inside a Power App. A healthcare provider in Victoria uses exactly that pattern: staff complete a form inside a Power App, the app calls the flow, then the flow writes the record into a SharePoint list and handles the follow-on admin. That covers more than 250 forms a month that used to be copied between systems by hand.
Scheduled cloud flows run on a recurrence you set, illustrated in Microsoft’s documentation as a “daily data upload to SharePoint or a database”. Nothing starts them but the clock.
Desktop flows are the robotic process automation half of the product. They drive an application’s interface directly, clicking and typing the way a person would, which is how you automate software with no connector and no API. They are the right answer less often than people expect, and they are the most fragile thing in the toolkit, because a vendor moving a button breaks them.
Generative actions are in preview, with one honest caveat. The flow types page lists them as a flow type, while Microsoft’s generative actions overview calls them “a new type of action” you add inside an existing flow. Worth watching, not worth building on yet.
For a cloud flow triggered by a real form end to end, see our Power Pages and Power Automate walkthrough. For what AI Builder and GPT actions add inside a flow, see AI in Power Automate.
What is a connector and what do standard and premium mean?
A connector is the pre-built bridge between a flow and a service. When a flow reads a SharePoint list, sends an Outlook email or writes a Dataverse row, a connector is doing the talking. Standard connectors come with a Microsoft 365 licence. Premium ones do not, and that one distinction drives most surprise licence bills.
Microsoft’s licensing documentation states that “Users with the free plan or one of the Microsoft 365 license plans can only access standard connectors, but most of the other license plans and trials provide access to premium connectors.”
In practice the standard set covers most of Microsoft 365: SharePoint, Outlook, Teams, OneDrive, Excel Online, Planner and Forms. The premium tier is where the heavier data connectors and most third-party business systems sit. Microsoft maintains the definitive premium connector reference, so check the reference before you build rather than memorising a list that moves. A Victorian healthcare provider we work with keeps its entire staff-forms build on standard connectors, which is why it needs no premium licence. That was a design decision, not luck.
Do you need a premium licence to run a flow?
Only if the flow uses a premium connector, and even then it depends on how the flow starts. Microsoft states that a flow without a premium connector runs on a Microsoft 365 licence. Where it gets expensive is that instant flows and automated flows are licensed against completely different people.
Microsoft’s licensing FAQ sets out the licence context in its answer on flow runs: “Automated and scheduled flows use the flow owner’s license context. Instant flows (button, Power Apps) use the invoking user’s license context.” Its answer on who needs a Premium licence then applies that context:
- “If an automated or scheduled flow uses a premium connector, only the owner needs to have a Premium license.”
- “If an instant flow has premium connectors, every user who runs the flow needs a Power Automate Premium license.”
A forty-person team running a premium instant flow needs forty licences. The same outcome delivered as an automated flow triggered by a list item needs one.
Our position is that licence context belongs in the design conversation, not on the invoice. Where a premium connector is unavoidable and many people need the result, ask whether the work can be triggered by an event rather than a button. Microsoft also documents a Process licence that licenses the flow rather than the users, which is worth pricing against licensing every person who runs it.
This is where the three-types-versus-five confusion stops being pedantry. Automated, instant and scheduled are not decorative labels on a list of five. They are what your licence bill is calculated from.
Premium connectors are not the only thing a Microsoft 365 licence leaves out. Microsoft lists the excluded capabilities as access to premium connectors “(except in Dataverse for Teams environments)”, business process flows within app context, custom connectors within app context, on-premises gateways within app context, robotic process automation and AI Builder. Desktop flows are that robotic process automation line, so a desktop flow is premium territory under a Microsoft 365 licence, with one carve-out Microsoft names: “Windows 11 users can try desktop flows in attended RPA for personal productivity in the default environment.”
What are the limits on a Power Automate flow?
Power Automate documents limits on how long a flow runs, how much history it keeps, how many actions one flow can hold and how hard it can hit a service. A run times out after 30 days. History is kept for 30 days. One flow can hold 500 actions. A consistently throttled flow is switched off after 14 days.
Only the throttling limit is about running too often. Here is the full set, all taken from Microsoft’s limits and configuration documentation.
| Limit | Documented value | What it means in practice |
|---|---|---|
| Run duration | 30 days | “After 30 days, any pending steps time out”, including approvals nobody actioned |
| Run retention in storage | 30 days | Run history older than 30 days is gone, so debug inside the window |
| Consistently throttled flows | 14 days | “A cloud flow that is consistently throttled is turned off” |
| Actions per workflow | 500 | “Consider using child flows to reduce the number of actions in a single flow or if you need more than 500” |
| Retry attempts | 90 | The ceiling you can configure, not the default |
| Retry maximum delay | One day | The longest gap you can set between retries |
| Retry minimum delay | Five seconds | The shortest gap you can set between retries |
Microsoft 365 licences also carry an action allowance rather than an unlimited one. The licensing FAQ documents it as “6,000 actions per day. 10,000 actions per day during transition period.” What counts towards it is the part people miss, and the limits documentation spells it out: “Both successful and failed actions count toward the limits. Retries and requests from pagination also count as action runs.” A flow failing and retrying spends the allowance the whole time it fails. Our own view is that when a team does hit a limit, it is rarely the action allowance. It is the 30-day run retention, because it removes the evidence at exactly the point someone goes looking for it.
Why do flows fail and does Power Automate retry on its own?
Flows fail for two different reasons. Transient problems are a service briefly unavailable or a connection dropping. Design problems are where the flow does the wrong thing reliably. Power Automate retries the first automatically, up to two times on the low performance profile and up to twelve on medium and high. It cannot retry its way out of the second.
Under the heading Default retry policy, Microsoft documents the low profile as sending “up to two retries at exponentially increasing intervals”, scaling to roughly ten minutes for the last retry, and the medium and high profiles as sending “up to 12 retries”, scaling to roughly one hour. Those are defaults, with a configurable ceiling of 90 attempts.
You do not pick the profile. Microsoft assigns it by plan, puts Microsoft 365 plans on the low profile and documents that “A cloud flow uses the plan of its owner”. So an automated or scheduled flow owned on a Microsoft 365 licence retries twice, not twelve. Manual flows, Power Apps triggered flows and child flows sit on medium regardless. Almost nobody checks this.
For anything beyond transient failure you need Run after settings, which Microsoft’s error handling guidance describes as a way to “specify what should happen if an action fails, times out, is skipped, or is successful”. Without them the flow simply stops. Microsoft does email repair tips to the flow owner, but they carry “actionable feedback about certain errors” only and the emails can be switched off in the flow’s properties. Do not mistake them for failure monitoring.
When a flow is not running at all, work through it in this order:
- Confirm the flow is turned on. Flows get switched off, by a person or by throttling, which Microsoft documents as happening after 14 days of consistent throttling.
- Open the run history and check whether it started and failed, or never started. That one distinction narrows the search immediately.
- Check the trigger condition. If it is filtering everything out, the flow is behaving exactly as built.
- Check the connection. Expired credentials are the most common cause of a flow that worked yesterday.
- Check who owns the flow. Microsoft documents that when the original owner leaves, the flow reverts to the low performance profile, which means tighter request limits and a shorter path to being throttled off.
What are the most common mistakes when building a flow?
Five errors account for the bulk of the flows we are asked to rescue: a flow that triggers itself in a loop, no error handling anywhere, a premium connector discovered at go-live, filtering in the wrong place and a flow that dies when its owner leaves the business.
The self-triggering loop. A flow triggers on an item being modified, then modifies that item. It triggers itself, and keeps going until throttling stops it. Fix it with a trigger condition that ignores changes made by the flow’s own account.
No error handling anywhere. The flow works in testing. It fails quietly in production three weeks later, and nobody notices until someone asks where the reports went. Run after settings and a failure notification cost ten minutes.
Discovering a premium connector at go-live. The flow is built, tested and approved, then someone works out that the connector to the finance system is premium and all forty people pressing the button need a licence. Check the connector tier before the build, not after it.
Filtering in the wrong place. A condition action inside the flow still costs you the run. A trigger condition does not.
An orphaned flow. Microsoft is blunt about this one: “If the original owner leaves the organization, the flow reverts to the Low performance profile.” Tighter request limits, fewer retries and the repair-tip emails still going to a mailbox nobody reads. Australia’s technology workforce is not getting bigger either: the Australian Computer Society, in the twelfth annual Australia’s Digital Pulse report prepared by Deloitte Access Economics, reported that technology employment fell 0.3% in 2025 to around 967,000, with another 259,000 technology workers needed over the next decade. That measures the size of the workforce rather than how often people move, but a tight market is not one where whoever built your flows stays forever. Put flows on a service account, not on someone’s personal login.
When is a Power Automate flow the wrong tool?
A flow is the wrong tool in four situations, and only one is about the technology. Three are about what you point it at: data that is not consistent, a process nobody has agreed or an integration heavy enough to belong somewhere else. The fourth is that the work needs its own screens for people to move through.
That last one is the common case. Power Automate has no interface for building screens and navigation, so if the job needs those, you want an app with a flow behind it. Our comparison of Power Apps and Power Automate covers where that line sits. The other three:
- The data is not consistent enough. A flow applies the same instructions to inconsistent data at speed, and produces inconsistent results faster. Fix the data structure first.
- The process is not agreed. Automating a process nobody has settled gets you a flow that needs rebuilding in a month.
- The integration is genuinely heavy. High volume, long-running or complex orchestration between systems is Azure Logic Apps or custom code territory, and our business automation work spans all three.
None of that makes Power Automate a weak tool. It makes it a specific one.
Frequently asked questions
Is a business process flow the same as a cloud flow?
No. A cloud flow automates work. A business process flow is a different thing: Microsoft describes it as a way to “help ensure that people enter data consistently and follow the same steps every time”, by defining a set of stages and steps shown at the top of a form in a model-driven app. Microsoft’s flow types page does not list business process flows as a Power Automate flow type at all, which is why the two are so often confused.
What is the difference between a cloud flow and a desktop flow?
A cloud flow talks to services through connectors, running in the cloud with no screens you design. A desktop flow drives an application’s interface directly, clicking and typing as a person would. Use a cloud flow wherever a connector exists, and a desktop flow only for software with no connector and no API.
How long does Power Automate keep flow run history?
Thirty days. Microsoft documents run retention in storage as 30 days, calculated from a run’s start time. Anything needed for auditing beyond that window has to be written out of Power Automate into a list, a table or a log while the run is still inside it.
Why is my Power Automate flow not triggering?
The usual causes are the flow being turned off, an expired connection, a trigger condition filtering the event out or the flow being throttled off after 14 days of consistent throttling. Check first that the flow is switched on, then open the run history to establish whether it started and failed or never started at all.
Can a Power Automate flow trigger itself in a loop?
Yes, and it is one of the most common build errors. A flow that triggers on an item being modified and then modifies that item will re-trigger itself until throttling intervenes. Add a trigger condition that excludes changes made by the flow’s own account, and check the run history for a sudden spike in runs.
How many actions can a flow run in a day?
Microsoft documents 6,000 actions per day for Microsoft 365 licences, with 10,000 during a transition period. The allowance belongs to a context rather than to a single flow: Microsoft states that “Action limits apply per context” so each user and each licensed flow gets its own daily limit independently. A Process licence carries a 250,000-action daily entitlement. Successful actions, failed actions, retries and pagination requests all count.
Where to go next
A Power Automate flow is a trigger, a list of actions and a set of documented limits that decide how far it gets. The trouble we are called in to fix usually comes back to a trigger doing something other than intended, a licence context nobody checked or a flow with no error handling running quietly wrong.
If you have a flow that keeps breaking or a process you think should be one, our Power Automate consulting team can look at what you have and tell you honestly whether a flow is the right answer.
