As this is my first post on the Microsoft Flow community site, I will start with a quick introduction.

I grew up in a little village in the Netherlands. After completing my studies I moved to the UK. Now 20 years later, I work as a Senior Consultant at Triad Group Plc. Since 2017 I have been a Microsoft MVP in Office Servers and Services. For several years I focused on delivering SharePoint solutions. In recent years this has expanded into the much wider Microsoft 365 offerings. My specialisms include Microsoft Teams, Microsoft Flow, PowerApps and Microsoft Forms. I frequently write about all these products on my blog SharePains, https://veenstra.me.uk.

In this post I'm looking at how to design your flows. Often when I see Flows created by less experienced users I find a number of mistakes. The common mistakes in Flow design I'm going to identify in this post.

First of all I would like to start with identifying the different layers of a typical Flow:

Data Layer



Presentation Layer

Process Layer

Data Layer

Typically you will find that the data that you manipulate in Flow will be stored in applications like SharePoint. But the data could really be anywhere and as the number of connectors grows you will probably find that you are less and less restricted by the where your data lives. I would not worry too much about where the data lives and if possible I would avoid replicating data. Just leave it where it already exists and then try to access it.

Presentation Layer

As your Flow interacts with users and systems there will be some form of data that is presented to users. This could be for example by an email, but you could also be updating a list item in the Data Layer using for example PowerApps.

Process Layer

The Process Layer is where the Flow work comes in. This is where you create your workflow and create a lot of the dynamic processes that act on data changes and user interaction.

I'm now going to look at a typical flow with some user interaction. Often business processes require multiple approvals. My record has been a process where potentially up to 16 people had to approve something within an organisation that I worked with. Imagine if you create a flow that requires 16 pieces of information. In this case it was a process that was triggered by the upload or change of a document in SharePoint and of course it was also needed to update the document properties during this Flow.

So you would now typically end up with 16 approval steps sequentially and some actions that update the document properties. As you might be able to guess you will now need to make sure that the Flows that are triggered by the updates made by your flow aren't restarting the process. This can become a major headache very rapidly.

How do you avoid this headache?

First of all if you have a need to update the triggering item while you are triggering your flow by the creation and modification of the same item then you will be better of creating a Flow that restarts often. Simply accept that with every change to the item your flow will restart. So don't think about voiding the restarts of the flow, start making use of it instead!

I'm going to start this flow with a When an item is created or modified trigger.

Within SharePoint I've created a list called ProcessList

My list item has a status field with the following 4 status values:

Created

Pending Approval 1

Pending Approval 2

Approved

Now within my flow I'm adding an initialize variable action. So now my Flow looks like this:

Why would you create a variable for the Status. Isn't the dynamic content just as good? Well it can be just as good however as you add more steps to your Flow it can become very confusing which Status you should select or which status you selected in the past. Now I will have a variable that will appear in my dynamic content at the top:

So now I'm ready to deal with the process. By adding a single switch to my Flow I'm adding something that looks like a Workflow construction also known as a state machine workflow.

So now every branch of the Flow can deal with part of my process. The only thing I need to make sure is that each branch updates the Status to the next part of my process.

So part of my Flow design is now to decide what my next status is. So at first you could consider something like this:

Created -> Pending Approval 1

Pending Approval 1 -> Pending Approval 2

Pending Approval 2 -> Approved

But what happens when my item isn't approved and one of my approvers decided to reject the item? Well first of all I will need to extend my status field with a value for Rejected.

Then my switch needs to be extended to include a Rejected option. And now it depends a bit on how I want my process to work, but I could decide to send the item back to the creator of the item so that they can correct the content of the item.

But whichever complexities the Flow may need each phase of my flow will deal with a simple small piece of the process.

Burt what if, ...

I have multiple item updates within my Flow?

When you update the item that triggered the Flow you could consider one of the following options:

1. Store the data of your updates somewhere else. This might not always be a valid option.

2. Create more status values so that each process becomes smaller and will only contain the minimum number of updates. Still this might not work.

3. Create an internal status field with the following values

In Progress Ready

Now within your flow, even before the switch that controls the status values we add a condition that checks the internal status. Whenever the internal status is In Progress we will not run the switch actions. Now all we need to do is at the begining of each branch of my switch set the internal status to In Progress and at the end of the branch set the internal status to Ready.

I hope that you have found this post useful. If you want to read more of my posts about flow or the other Microsoft technologies that I specialise in please have a look at my blog SharePains