Someone in finance asks why the invoice reminder went out twice on Monday. You open My flows to check.
There are 43 of them. Six start with “Copy of”. Two are called “Test”. One is called “Flow 2 FINAL”. The one you need is somewhere in there, and the only person who knew which one left in the spring.
I hit this myself, so I went looking for how other makers handle it. It turns out a lot of people share the same pain. Everyone I found had built their own system from scratch. One maker runs over 500 flows from a single account. Several said, more or less, that it is crazy Microsoft does not have a better way.
They are right that Microsoft does not hand you a scheme. The My flows page is a flat list. There are no folders. So the order has to come from you, and it comes from three things: the name, the solution, and the description.
Why the list gets out of hand
Nobody sets out to build 43 flows. You build one for a form. Then a copy for a second form. Then a test you mean to delete. Each one makes sense on the day you build it.
The trouble shows up later, when someone else opens the list. A flow name is the only thing My flows shows you, and most names describe the trigger (“When an item is created”) or nothing at all. Nothing in the list says which team owns it, what it changes, or whether it still matters.
So put the answers where the list already looks: in the name, in a solution, and in the description.
A name that sorts itself
Start every flow name with a short team code, a dash, then a verb and an object:
OPS - Notify facilities when a room booking is cancelled
FIN - Send weekly invoice approval reminder
HR - Create onboarding tasks for a new hireThis was the most useful idea I came across while searching. One maker puts a three-letter stakeholder prefix on every flow, for example OPS - Submit Request or FIN - Generate Report, so the owning team is clear at a glance. I tried it in a test environment and it does what it promises.
My flows
The team code is the first thing you read, so the list groups itself when you sort by name. Checked in a live tenant in October 2026.
A few rules keep it working:
| Rule | Why |
|---|---|
| The team code comes first, always in capitals | Sorting by name groups each team together |
| Pick the codes once and write them down | OPS and OPER in the same list defeat the point |
| Start the rest with a verb | ”Send”, “Create”, “Notify” says what the flow does, not when it runs |
| Name the thing it changes | ”invoice approval reminder” beats “reminder” |
| No dates, no “v2”, no “FINAL” | Version history lives in the flow, not the name |
If you have flows that run in a chain, add a shared label and a number after the code, like FIN - Invoices 1 - Collect and FIN - Invoices 2 - Approve. Other makers do this so the order is obvious at a glance.
To rename an existing flow, open it, select Edit in the Details card, and change Flow name.
Put each team’s flows in a solution
Names sort the list. A solution goes further and gives each team a list of its own.
Think of a solution as a project folder for flows, apps and the pieces they use. Microsoft describes solutions as the way you move apps and components from one environment to another, so the same set of flows can go from a test environment into production in one step. You may want that later. For now, the folder is what you are after.
You do not have to rebuild anything. A solution can take flows you already have.
Make the solution
- Sign in to Power Automate and select Solutions in the left menu.
- Select New solution.
- Give it a Display name that uses the same team code, like
OPS - Operations flows. - Pick a Publisher and select Create.
Solutions > New solution
Reuse the team code here too, so the solution and its flows sort the same way. Checked in a live tenant in October 2026.
Add the flows you already have
- Open the new solution.
- Select Add existing, then Automation, then Cloud flow.
Add existing > Automation
Cloud flow sits under Automation, not at the top of the menu. Checked in a live tenant in October 2026.
- Switch to the Outside Dataverse tab. That is where flows that are not in any solution yet live. The From Dataverse tab only shows flows that are already in one.
- Tick the flows for this team and select Add.
Outside Dataverse
Read the line under the title before you select Add. It is the one-way part. Checked in a live tenant in October 2026.
Microsoft’s steps for this note that some flows cannot be added to a solution. If a flow is missing from the tab, that is usually why.
If you have hundreds of flows, your admin does not have to tick boxes. Microsoft provides a PowerShell cmdlet, Add-AdminFlowsToSolution, that moves many flows into a solution at once.
What you get for it
Two things changed on my test flow the moment it moved in.
First, ownership. Before the move, the flow’s details panel said: “This is a non-solution flow. The owner cannot be changed.” After the move, that line was gone. For a team, that matters. Microsoft notes that a solution flow can be owned by a Dataverse team rather than one person, so it does not walk out the door with whoever built it.
Flow details > Edit
A description written for the next person, and the owner warning that disappears once the flow is in a solution. Checked in a live tenant in October 2026.
Second, the panel stopped saying some options were unavailable “because this flow is not in a solution”. Microsoft’s list of what needs a solution flow includes drafts and versioning, which on its own is worth having once a flow matters.
Check where new flows land
Once the old flows are sorted, make sure new ones start in the right place.
There is an environment setting for this. In the Power Platform admin center, open the environment, then Settings, then Product, then Features. Look for Create new canvas apps and cloud flows in Dataverse solutions.
Admin center > Settings > Features
On in a brand new Developer environment, before I touched it. Older environments may not have it on. Checked in a live tenant in October 2026.
When I created a fresh environment for this post, Cloud flows was already on. With it on, new flows are created inside a Dataverse solution instead of floating loose. Your older environments may be different, so check rather than assume. When I switched it on by hand, the admin center asked me to confirm first.
The setting does not know which team a flow belongs to. Microsoft recommends that makers work in their own solutions rather than the defaults, so makers should still start from their team’s solution (Solutions, open it, New, Automation, Cloud flow) or add the flow afterwards.
Write the description for the next person
The description is the one field almost everybody leaves blank. It is also the first thing a stranger reads when they open your flow.
Open the flow, select Edit in the Details card, and fill Description with four short lines:
Trigger: a Room Bookings item is set to Cancelled.
Does: emails facilities with the room and date.
Touches: SharePoint (Room Bookings list), Outlook.
Owner: Operations, Dana P. Built Oct 2026.That is enough for someone to decide in ten seconds whether this is the flow they want. “Touches” is the line people skip and the one that saves the most time, because it tells you what breaks if you turn the flow off.
Copilot in the flow designer can write a description for the current flow for you. It is a fine first draft. It cannot know who owns the flow or why it exists, so add those yourself.
If a flow needs more than four lines, put the longer build notes somewhere else and say where in the description.
Keep a register of what each flow touches
Names, solutions and descriptions all live inside Power Automate. A register lives outside it, which is why it still works when you cannot get into Power Automate at all.
Several of the makers I found keep a Microsoft List of their flows, with a link to each one. The most useful column I saw is a choice column for connectors. When a connector has an outage, they filter the list and know straight away which flows are likely to fail.
A register that holds up has these columns:
| Column | Type |
|---|---|
| Flow name | Single line of text, using the naming rule |
| Link | Hyperlink to the flow |
| Team | Choice, using the same codes |
| Owner and co-owner | Person |
| Connectors | Choice, multiple values |
| What it touches | Links to the lists, libraries or forms |
| Status | Choice: live, paused, retiring |
| Last reviewed | Date |
If you are a Power Platform admin, there is now a built-in version of the connector column. The Power Platform inventory in the admin center lists every cloud flow in the tenant, and a Connectors column (in preview) shows what each flow uses. Changes show up within 15 minutes, and you can download the whole thing to a CSV.
Only admins can open it, though. Inventory is for roles such as Global administrator and Power Platform administrator. A maker in operations will not have it. For them, the List is still the answer.
Keep it current
A naming rule decays the first week nobody checks it. Three habits stop that:
- Name it before you save it. The flow name is the first box when you create a flow. Use the rule there, not “later”.
- Start from the solution. Build new flows from inside your team’s solution so they never need moving.
- Review once a month. Sort My flows by name. Anything without a team code gets renamed, moved, or deleted. Update the register while you are there.
You do not need a tool for this, just one person who owns the rule and checks it.
What this does not fix
Moving a flow into a solution is one way. Microsoft’s wording: flows can be added into a solution “but there’s no way to revert back”. The panel in the screenshot above says the same thing in smaller type.
That matters because of a story I came across while researching this. They moved all their flows into solutions at once, things broke because of licensing they did not have, and they could not move the flows back. They rebuilt them from scratch.
So move one flow first. Test that it still runs. Then move the rest of that team’s flows. If your flows use premium connectors, check licensing with your admin before the first move, not after.
Solutions also need a Dataverse database in the environment. When I opened Solutions in the default environment of my own test tenant, it said “No database found”. If you see that, adding a database is a decision for your admin, not something to click through. I used a separate Developer environment for this post and deleted it afterwards.
The storage cost is small. Microsoft’s own worst case is a flow definition of 10 KB, which works out to 100 MB for 10,000 flows.
Last, a tidy name will not fix a broken flow. A well-named flow that sends the invoice reminder twice still sends it twice. You will just find it faster.
The bottom line
Pick your team codes today and rename your flows to TEAM - Verb object. Make one solution per team and add the existing flows with Add existing, one test flow first. Then write four lines in each description (trigger, does, touches, owner), so the next person who opens one of your 43 flows can tell what it does without asking you.