cancel
Showing results for 
Search instead for 
Did you mean: 
Pieter_Veenstra

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 😞

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 🙂

Anyway, many thanks for your confirmation.

R.

Anonymous

Hi @Pieter_Veenstra ,

After spending many hours on what I thought was going to work I changed something and my flows continually run and I've moved things around so much I no longer know where in the heck I'm at!

Prior to Flow, I dabbled a little in SP designer some and also Nintex. I have no developer or busines process background and I've pretty much learned by trial and error and from great posts such as yours.

Your 'state machine' reminded me of the Nintex workflows I worked on and I thought I might try it out. I have the switch with 10 statuses but I cannot figure out where the internal status fits in. It's possible I just need some sleep and it will come to me. Also, a couple of my statuses have approvals as well. Basically the business case is a process tracking tool that keeps track of every action and outcome all within a single list. I've used PowerApp to customize the list form but didn't include any functionality to send emails. My statuses are basically toggle buttons and when one is toggled to True something happens. I have a lot of Update Item actions and I've lost track of which Update Item goes with which field token. Do you think your 'state machine' model is a good fit with what I'm trying to do, and if so could you walk me through the conditions for the Internal Status?

I've watched a few of your tutorials and especially enjoyed the videos with @JonL. It gives me hope that one day I will get the logic down and be able to create beautiful things.

Any help would be greatly appreciated!

Best,

SheryK

Anonymous

I like to put the "Check Status for Ready" condition at the beginning of the flow (in the same condition that checks to make sure the Flow is not a false re-triggering), and "If No" -> Terminate the Flow ("cancel"), "If Yes" -> do nothing (essentially continuing the Flow all the way to the Switch layer).

 

No need to continue executing everything else. It's also one less layer the rest of your process will be in, due to a max layer of 9 in Flow.

About the Author
  • Experienced Consultant with a demonstrated history of working in the information technology and services industry. Skilled in Office 365, Azure, SharePoint Online, PowerShell, Nintex, K2, SharePoint Designer workflow automation, PowerApps, Microsoft Flow, PowerShell, Active Directory, Operating Systems, Networking, and JavaScript. Strong consulting professional with a Bachelor of Engineering (B.E.) focused in Information Technology from Mumbai University.
  • I am a Microsoft Business Applications MVP and a Senior Manager at EY. I am a technology enthusiast and problem solver. I work/speak/blog/Vlog on Microsoft technology, including Office 365, Power Apps, Power Automate, SharePoint, and Teams Etc. I am helping global clients on Power Platform adoption and empowering them with Power Platform possibilities, capabilities, and easiness. I am a leader of the Houston Power Platform User Group and Power Automate community superuser. I love traveling , exploring new places, and meeting people from different cultures.
  • Read more about me and my achievements at: https://ganeshsanapblogs.wordpress.com/about MCT | SharePoint, Microsoft 365 and Power Platform Consultant | Contributor on SharePoint StackExchange, MSFT Techcommunity
  • Encodian Owner / Founder - Ex Microsoft Consulting Services - Architect / Developer - 20 years in SharePoint - PowerPlatform Fan
  • Founder of SKILLFUL SARDINE, a company focused on productivity and the Power Platform. You can find me on LinkedIn: https://linkedin.com/in/manueltgomes and twitter http://twitter.com/manueltgomes. I also write at https://www.manueltgomes.com, so if you want some Power Automate, SharePoint or Power Apps content I'm your guy 🙂
  • I am the Owner/Principal Architect at Don't Pa..Panic Consulting. I've been working in the information technology industry for over 30 years, and have played key roles in several enterprise SharePoint architectural design review, Intranet deployment, application development, and migration projects. I've been a Microsoft Most Valuable Professional (MVP) 15 consecutive years and am also a Microsoft Certified SharePoint Masters (MCSM) since 2013.
  • Big fan of Power Platform technologies and implemented many solutions.
  • Passionate #Programmer #SharePoint #SPFx #M365 #Power Platform| Microsoft MVP | SharePoint StackOverflow, Github, PnP contributor
  • Web site – https://kamdaryash.wordpress.com Youtube channel - https://www.youtube.com/channel/UCM149rFkLNgerSvgDVeYTZQ/