Elegant pattern for implementing state machines with Microsoft Flow…

December 2018 update : I’ve suggested a more scalable pattern : the Flow controller pattern.

Most workflow engines & tools I know (Nintex, K2, DataPolis, .Net Workflow) support state machines; at some point your workflow is so complex that you really really need it. I’m a very strong supporter of state machines, but my favorite tool, Microsoft Flow doesn’t support it (yet?). Only sequential workflow is supported so far.

In this blog post and to illustrate what I mentioned in April 2017, I will illustrate how I solved this specific issue and I believe this could become a pattern for your future flows.

Here is the (simplified) problem :

A use creates a document in SharePoint. This document must be validated by a person called “Val”;  when Val has validated the document, it must be validated by the “secretariat”; when this is done, it must be validated by the “Boss”; then the document will be signed by the boss (electronic signature) , transformed into PDF and published to external users. Of course the boss can reject the document and send it to the secretariat or to val; Val can also reject the document.

Basically the workflow looks like this :


Good luck to create this with Microsoft Flow! Mind you, you might end up creating plenty of not maintainable loops, conditions, approval and you will scratch your head (as I did). And what if you don’t just have 3 approval levels, but 10 or 15..or 100 (…just kidding) ?

When you are desperate you become creative and you start thinking out of the box:

Here is what I did :

  • create a loop
  • create a switch
  • each branch of the switch is a state
  • specify where you come from and where you want to go
  • in the loop specify how you exit the loop

That’s it : – )

Here is the whole implementation (click to zoom)


Here is the detail of a specific state (click to enlarge) :



You can extend each branch (state) if needed by managing the timeout : if the Secretariat doesn’t react on time you can ask it to approve again :


So you get this :


Now I know you next question : how does the system know that when the Boss rejects the document, the request must go to Val or to the secretariat ?

Indeed in the approval form, we only have 2 buttons so far : approve or reject. I know that custom forms will be available in the future, but in the meantime we need to rely on the comment box in the approval form : if the boss types “VAL” or “val” or “V”, the flow will go to VAL, otherwise it will go to the secretariat. He can even type V or Val followed by a comment. This is totally acceptable until custom forms are made available and I believe this is super important (are you listening Flow team ? 😉  ).


One of the downside of this approach you will face with this approach is that the until loop is opaque when the flow is running, you don’t see what’s going on (please Flow team, fix this asap).


However you can still see the current flow state by storing in a custom “status” column in your SharePoint List or Document library. And if you want more (history, statistics, analytics, check one of my previous blog post “Flow approval escalation with analytics“).

In summary: each state become a branch in a switch. This is simple, easy to implement, easy to maintain, it scales and it works in the current implementation of Microsoft Flow. This approach also scales because can can easily add many states (or branches) and each branch can also be implemented as a Service Flow (nested Flow) if needed.





Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s