Is there anything that stops you from using Microsoft Flow? Whenever this question is asked there are some people responding, “State Machine!” Many people are comparing Microsoft Flow with SharePoint Designer workflows or Nintex. Although SharePoint Designer has never had State machines, Nintex has had a State Machine action for many years. Over the past years the state machine pattern has become a standard way of developing complex processes. Just in case you are new to state machines please have a look at Vadim’s blog post.  Many years ago I wrote a post about State machines in Nintex too. Do I like state machines? Of course I do! But are they really necessary?

My 2 posts about developing state machines in Flows, will help to run a single flow with a state machine alike process and the template for the state machine can also help you. Of course, Serge Luca’s Flow Controller is beating all of these state machine ideas when you implement more complex processes. In this post Serge explains how to create a separate flow controlling the process while the worker flows do the work.

Okay, so we’ve got plenty of options to organise our complex flows. Once you have read through all of these posts I would like to ask the same question again. Do we really need a state machine in Flow?

I would like to list my top 5 improvements that I would like to see in Microsoft Flow. I will include links to user voice ideas. Please do up vote the ideas if you agree that these are more important that a state machine. If you don’t agree then please vote for the state machine idea.

#1 Copying actions

Wouldn’t it be great if you could copy actions? When you’re flow uses similar actions you currently can copy fields form one action to another, but copying exiting actions is not possible yet.

#2 Trigger on a specific list column in SharePoint

If it was possible to trigger only on a single or combination of columns in SharePoint then that would reduce the number of runs of your flows. As an added bonus this would potentially also help with making the above State Machine processes more efficient.

#3 Add @mention in the MS Teams connector

When posting message to Team you can’t mention a person, a team or a channel. This is something that is a big miss when working with teams.

#4 Get previous values of updated items

Similar to the item #2 it would help if we could get to previous values of things. This is probably just as relevant for the CDS connector and other data storage connectors. Once again this could also help with the implementation of state machines using the switch step as described in the above posts.

#5 Multiple triggers for one flow

When you attach a flow to a list or library and then create multiple copies of the site using templates, you will end up with many copies of the same flow. This could be for example when you create project sites with flows. Having a construction to replicate flows or even better have a single flow would be a great win. I’m aware of solutions where you can subscribe to lists using web hooks, but this is not really in the scope of no code developer.

Do we really need state machines? If you think so then please up vote the state machine idea.

 

 

 

 

 

 

Advertisements