Today I got an interesting question submitted by one of my followers on the Share your pains page. How do you choose between multiple flows or a single flow?
I got the following question today:
Hi! I want to know if it is better to have multiple flows interacting with one file is better than having one flow with parallel branches (with the same actions as if there were multiple flows) interacting with one file. I need to update a single Excel file (Update Rows) with information from 5 different Excel files, all done at the same time (it is a scheduled flow). If you need any further info please ask. Thanks a lot
This question actually contains quite a lot of the aspects that should be considered.
Other things I would consider are:
Recently I completed a Power Platform project which both included Power Apps and Power Automate. The general configuration was quite okay when I started to get involved in the project however some improvements could be made.
When I started I found
Each of the 5 copies were for different environments (Dev, Test, Production and so on)
Some quick sums make this into 160 flows and 30 Power Apps all stored in one Power Platform environments (the default one of course!). As updates were made to the flows and apps the names of the flows and apps would change and the names would include the environment and the version number of the flow/app.
Yes, indeed deployments would take longer than a day as deployments were done manually. Automation could be considered, however that is not an easy task. Also building solutions rather than standalone flows and apps can help, however there are still a few outstanding issues in this approach
It is also important to consider developing your flows in a generic way. For example if you interact with SharePoint you might want to consider the steps described in Creating generic flows in Microsoft Flow using the SharePoint connector.
One important difference between parallel and multiple flows is that the parallel branches will all wait for each other to complete.
If your flows use parallel branches then each branch will have to complete before the overall flow will complete.
On top of that actions like terminate will cancel all branches. is this what you intended? It might be a good thing but it might also be a bad thing.
You could of course also consider a state driven flow and use a switch to select which branch needs to run. However this means that you might end up with your overall process run is spread over multiple flow runs. This might not make debugging of your flows any easier.
There are different ways that a flow can be started
Depending on which way a flow starts you will find that the person running a flow will be different. When you start an instant flow (press a button or a for a selected item flow) then the flow will run as the user starting the flow. When you have a scheduled flow however the flow will run as the owner of the flow.
When you need to access files, you need to consider who need to have access to a file.
Also file locking issues may be affected depending on who runs the flow.
What starts the process? quite often an update to a file should start a flow. When I look back at the question at the beginning of this post, potentially the updates of 5 different excel files will need to trigger part of my process.
If this means that you would want to use these Excel file updates as a start for each part of the process then you might be bound to have 5 separate flows. However if you find that you could start a single flow when only the last of the 5 files has been updated then you could consider a single flows that reads the content of all 5 data sources.
When you update data you will always have to look out for conflicting updates. It doesn’t really matter if your data lives in SharePoint, SQL Server or Common Data Service, if you cannot guarantee the order of the updates happening and you are updating the same piece of data then you are likely to end up with random results.
I just spend a lot of this post convincing myself (and you) that a single flow is better. But actually there are good reason to separate flows.
I do in general tend towards creating as few flows as possible. However when you hit some of the technical limitations you might be forced towards multiple flows.
As mentioned above the multiple files in multiple libraries that trigger my process.
Also, when your flows become complicated you might add some scope boxes to clean up a lot of actions. As shown below it can be a lot cleaner if you can collect multiple actions in a single scope box.
That way you can name and document the collection of action in a single place.
Even if you do have multiple branches, putting each branch into a separate scope box will keep your flow look simple.
Have written many posts about performance. Although a single flow or multiple flows might hardly make any difference, I am sure that there will be performance reasons that you might have to consider.
When you have multiple flows all repeating the same set of actions then you might find that for example the throttling of connectors kicks in. Reducing the number of connector calls may sometimes be solved by running less flows.
So to answer the question, what is better Multiple flows or 1 single flow?
It all depends. You might even find that as you develop your simple flow that over time you will want to split your flows or merge multiple flows. With the Power Platform it is quite easy to change your mind whenever you need to.
Last week Shane Young asked me about calculating the Sum for a SharePoint column in…