Are you running out of runs with Microsoft Flow?

As described in my post from last week  I quite like to keep my flows in Microsoft Flow short. i’m happy with wide flows but I want to keep them short. This especially works when I develop state driven workflows. Each state of the workflow becomes a branch in switch that controls my flow.

There is one problem though, every time the triggering data is updated a new instance of flow is kicked off. And you are likely to get the feeling that Microsoft Flow is running away with your available flow runs.

The big question now is how do you solve the problem of running out of flows.

1. Ignore it and just pay for the flows
2. Do not ever update the triggering item other than during the initial trigger
3. Trigger a process only once on creation of the data
4. Share your flow quota across the organisation

Ignore it and just pay for the flows

Ok, this is probably not your favourite option. I’m not saying that you shouldn’t pay for the plans available. There can be perfectly good reasons for this. I would also not break the good flow design just to reduce any number of flows.

Do not ever update the triggering item other than during the initial trigger

Now we are looking at creating a flow that starts on the creation of an item only and any updates that we want to make cannot be made to the triggering item. There will be very few processes where you could do this. You could do this however with a request system, where the request comes in and the original request remains as it is originally. Additional data could be stored in different data sources. Quite quickly this could result in your data being all over the place. So it is likely that you wouldn’t like this idea.

Trigger a process only once on creation of the data

Now we are looking at a process where the creation of the item starts the process and there will be a flow alive throughout the life cycle of the item. As I like to keep my idea of state machine workflows I could imagine that the status of the flow is kept in a variable and a Do-Until keeps the process alive

So I would end up with something like this:

This options is probably my preferred option as I keep the flow controlled by the status. If I want to I can even update the list item with a status so that users can see where the process got up to without me triggering the flow again. However there is one major downside. If my flow fails and I want to restart my flow after I have fixed the issue the flow will not be automatically restarting.

Share your flow quota across the organisation

Now, we will look at the situation where you already created a flow. You don’t want to reorganise your flow but you are running out of runs.

It is possible to Share flows with other people and groups of people. Where initially a flow is just own by the user that created the flow.

You can share a flow and then multiple people can own your flow

And when you use the manually trigger flows you can also set the Run-Only users.

Ok, so I can now share flows, but I tried to run fewer flows! Well when you share flows you actually share the run quota as well. Therefore this might be an option to use more of your free quota and you  are less likely to run out. Imagine if you are on plan 1 then it is even less likely that you need to upgrade to plan 2.