A client put it to me better than any licensing guide ever has: “This flow runs eleven times a day. Why does it need the same license as the one that processes every invoice in the company?” She was pointing at a Power Automate Process license — 250,000 actions per day of capacity — assigned to a flow that consumed maybe four hundred. Multiply that by the fifteen or twenty small automations a typical department accumulates, and you are paying enterprise prices for flows that would not stress a pocket calculator.
As of the July/August 2026 feature update, that math finally changes. Flow groups are generally available in Power Automate, and they let up to 25 cloud flows share a single Process license. If you have been quietly avoiding Process licenses because of exactly the scenario above, this is the announcement worth reading closely.
Why the Old Model Pushed People Into Bad Habits
Until now you had two clean options for licensing a cloud flow. You could run it under a per-user plan, which ties the flow to a human being — fine until that human changes roles, leaves, or simply stops being the right owner for a business-critical process. Or you could assign it a Process license, which gives the flow its own standalone entitlement of 250,000 actions per day — robust, ownerless, and dramatically oversized for most departmental automations.
The pricing gap between those options produced a familiar anti-pattern: makers cramming unrelated logic into one sprawling mega-flow, because one licensed flow was cheaper than five small ones. I have untangled enough of those to tell you the savings were never worth it. A flow that approves expenses, syncs SharePoint, and emails a weekly report is not an automation; it is a junk drawer with a trigger.
Licensing pressure should never dictate architecture. With flow groups, it no longer has to.
What Shipped
A flow group is exactly what it sounds like: a named container, scoped to one environment, that holds up to 25 solution-aware cloud flows. You assign a single Process license to the group, and every member flow — child flow runs included — draws from the shared pool of 250,000 actions per day. Consumption is measured against the group total, not per flow.
You will find the feature in the maker portal under More > Flow groups (pin it if you plan to use it — you will). Creating a group takes about a minute: New flow group, give it a name, assign a Process license under Process licenses, and select Create. If creation fails with a message that PowerAutomatePerProcess capacity is 0, your environment simply has no unassigned Process license available — add capacity first.
Adding flows works from either direction: open the group and select Add flow to browse the environment’s solution-aware flows, or open an individual flow’s details page and switch its licensing to Shared Process license (flow group). The group page shows a running tally in the format n/25 flows | n Process licenses | n actions/day, which makes capacity reviews refreshingly boring.
The Fine Print You Should Actually Read
Microsoft drew the eligibility lines tightly, and a few of them will surprise people:
- Solution-aware flows only. A flow living loose in My Flows cannot join a group. If your organization still builds outside solutions, this is one more reason to stop.
- One environment per group. There are no cross-environment groups. Dev, test, and production each need their own.
- No license stacking. A group gets one Process license and one 250,000-action pool. If a single flow genuinely needs more than that, assign it a dedicated Process license on its own — groups are not the tool for your heaviest workloads.
- One group per flow. Membership is exclusive; a flow cannot draw from two pools.
- Cloud flows only. Desktop flows and business process flows are not eligible, and neither are flows already running under a per-user plan.
⚠ Important: removing the Process license from a group — or switching a member flow’s plan — breaks the association and suspends the dependent flows until they are relicensed. Treat the group’s license assignment the way you treat a connection reference in production: nobody touches it casually.
The ALM Trap Nobody Will Warn You About
Here is the caveat I predict will generate the most support tickets: flow group membership does not deploy. Ship your solution to test or production through a pipeline and the flows arrive, but the grouping stays behind. In every target environment you must recreate (or verify) the group, add each deployed flow to it, assign a Process license, and confirm each flow is on and licensed.
Key Insight: a flow group is a licensing construct, not a solution component. Put the post-deployment steps — create group, add members, assign license, verify — into your release checklist now, because nothing in the pipeline will fail loudly if you forget. The flows will simply run on the wrong entitlement, or not at all. This is the same discipline I argued for in my 2026 release wave 1 mid-wave checkpoint: the features land automatically; the operational habits around them do not.
Which Flows Belong in a Group
Microsoft’s own guidance here is sensible. Flows running roughly 5,000 to 50,000 actions per day are the sweet spot — big enough that per-user licensing feels wrong, small enough that twenty of them coexist happily in one pool. Anything consistently above 100,000 actions per day deserves its own dedicated Process license, because a shared license is a pizza, not a buffet: when one flow takes six slices, everyone else goes hungry.
Before you group anything, open each candidate flow’s Analytics page and check the 28-day Actions chart. You are looking for two things: the average daily consumption (to size the group) and the shape of the curve (a flow with violent month-end spikes can starve its groupmates precisely when they are busiest). Do the arithmetic on the worst day, not the average one.
Governance Notes Before You Roll This Out
A few practices I will be recommending to every client adopting flow groups: name groups after business capabilities (“Finance – AP Automation”), not after teams or people, so the name survives reorganizations. Review the capacity tally monthly — the group page makes this a thirty-second job. Record the group-to-license mapping in the same runbook that tracks your connection references and environment variables. And resist the temptation to build one giant 25-flow group per environment just because you can; three groups aligned to three business processes will be far easier to reason about when capacity gets tight.
My client with the eleven-runs-a-day flow? Her department’s eighteen small automations now fit in two flow groups on two Process licenses, with headroom to spare — down from a licensing quote that had effectively frozen their roadmap. That is the real story here. Flow groups will not make your automations faster or smarter. They make honest architecture affordable, and that is worth more: you can finally build five small, well-named, single-purpose flows without a spreadsheet somewhere punishing you for it. Licensing is architecture, whether you design it or not — now you can design it.
