cancel
Showing results for 
Search instead for 
Did you mean: 

Develop Flows Like a Pro!

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.

 

TriggerWhenCreatedOrModified.PNG

 

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:

 

VariableStatus.PNG

 

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:

 

 StatusVariable.PNG

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.

 

Switch.PNG

 

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

  1. In Progress
  2. 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.

 

InternalStatus.PNG 

 

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

 

 

 

 

 

Comments

This is really great! Thanks so much for sharing with us. I know that often times as i build deep flows my Dynamic content list can become twenty scrolls long! I'm going to try this method next time as well.

Cant wait to see what you write up next!

In this post, you suggest "...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!"

 

This of course counts against the Flow quota. Any suggestions for limiting the flow runs and the expense?

@DCrighton, If you are worried about the number of runs then indeed you could consider a bit more of a compicated solution as option 3 in my post here.

 

I tried to keep things simple for this post and intrduced the status driven Flow.

 

If you create a do-until around the switch then you would avoid the number of runs. However you would probably need to go for a trigger that is only firing on creation. Then restarting the flow could become a painful task.

 Should have know you already had a post for that option. Thanks for sharing Pieter!

Hi Pieter, clever idea.

let me ask you what you mean under "field" here: "Create an internal status field with the following values".

Field might not be variable, because new instance of flow will not take it over

It might not be als SP List column named internal status, because it will not work. Setting its value to Ready at the end of branch is and edit, which will re-trigger flow, and internal status is alredy Ready Smiley Sad

This should be something like variable or SP Item property...

Or did I misinterpered something?

Thx a lot

Hi Robert,

If the field is part of the triggering item then indeed setting the Ready flag could cause the flow to trigger. Therefore this will need to be a piece of data that isn't affectig the triggering item. You could keep a second list for example holiding links to the item and the status field mentioned.

I was afraid, you will tell me, it needs another status list for internal status Smiley Happy

Anyway, many thanks for your confirmation.

R.

Meet Our Blog Authors
  • Co-founder of https://plumsail.com, Office 365 and SharePoint expert. Passionate about design and development of easy to use, convenient and flexible products.
  • Microsoft Business Apps MVP. Owner of ThriveFast, an Office 365 consulting company.
  • 7x Microsoft Business Solutions MVP (CRM)
  • Solution Architect with Slalom, and organizer of the Boston Office 365 User Group, and long term SharePoint/Office 365 veteren. Find more at http://www.davidlozzi.com. Follow @DavidLozzi
  • I'm keen in MS technologies, SharePoint, Office 365 and development for them
  • Michelle is an Office 365 solution architect in Twin Cities, MN. She has been delivering business collaboration solutions for years with her focus on SharePoint and Office 365. Michelle is a recent board member of the Minnesota Office 365 User Group and has been a member of the SharePoint community since 2009. She is a frequent speaker at MNSPUG and SharePoint Saturday and co-chaired the Legal SharePoint User Group for 4 years. Her most frequent projects have involved rolling out a large deployment of Office 365, SharePoint Online intranet, build of a "CHAMPS" Office 365 user adoption program and most recently, SharePoint On-Premise to Online Migration. Michelle is very excited about cloud technology as it is shifting her IT Pro focus to collaboration strategy and technical adoption.
  • I'm a Microsoft Office Servers and Services MVP with a special interest in SharePoint, Office 365, Microsoft Flow, Microsoft Teams and PowerApps. I work at Triad Group Plc ( https://triad.co.uk)
>