It might be a little exaggerated on the screenshot below, but this illustrates the problem well:
There are two flows, both having the same name, both having the same triggers and actions… so what’s the difference?
The difference is, of course, in the details. Which Dataverse table is that trigger linked to and what email is sent there?
However, for a small flow like that, it probably would not take long for a new developer to figure out what the flow is doing. Imagine a flow with tens of different actions, all having named more or less identically (using system-provide names) – no one would feel comfortable having to figure out the exact purpose of such flows.
This is why it might be much better to follow some sort of naming convention when developing Power Automate flows. For example:
There, it’s much better. When looking at the list of flows, I can find the one I need quickly now. And I don’t need to expand each and every action to see what’s happening inside, since they are all named in such a way that I can just find the one I need.
This does take a bit of extra time to rename things, but it’ll pay off in the long term once you need to make change to an existing flow a year later when all those tiny details have already been wiped out of your memory (or, possible, when a new developer has to do it instead).
In many cases, when looking at the flows, you’ll be looking for those which are responsible for the “business function” that’s not working or that requires updates, so that’s why I tend to put a table name and/or a “function name” right in the flow name then follow up with a very short summary of what the flow is actually doing.
As for the actions, we cannot describe all the details right in the action name, but we can still be somewhat specific, and it’s not meant to be a full-blown documentation – it’s more of a hint to whoever will be looking at the flow trying to figure out what’s going on there, but even just having a hint makes a difference.