The goal of this post is to check back on the progress of Microsoft Flow after some time not using it and describe the changes.
What is MS Flow?
It’s an automation tool, good for replacing tasks we do manually and repeatedly that don’t involve specific 3rd party software, ie. Accounting SW.
It works with many connectors which provide function specific to the program/service you are connecting to – triggers (event that starts a flow) and actions (specific task you can do in a flow). You can check the list here.
Current environment and UI
The flows are created in the author’s account. They can be then shared with the rest of the team and they become Team flows.
If a company has Office 365 plan and Flow enabled, all the users can use it “for free”. There are as well other pricing options.
There were many updates to the features and UI since I used Flow the last time (end of 2016):
- We can now move the steps in a flow and reorganize them.
- There is great support for expressions and combining expressions with dynamic content, ie. values from SP list.
- We can initialize variables and use them throughout the flow, same as datetime objects.
- There is better documentation which looks to be merged with Azure Logic Apps in some parts because it shares the same expression language and object definitions.
In the picture below you can see various options for Actions that you have with the built-in connectors.
Outcome of using flows
The benefits of having flows instead of manual tasks are quite obvious but here are some of the most important ones:
- less errors compared to manual tasks
- better logging/overview of history
- joy due to not having to repeat boring manual tasks
saved time (example: A recent flow we made for one project team could save about 10 mins/month per developer. Then the numbers start to be interesting – if we had 10 developers in that team it would amount to 20h saved every year.)
Technical “aha” moments
I found out several interesting issues that needed to be solved when trying out MS Flow. Here I’d like to point them out because others will most probably hit them as well.
- Comparing dates – Always format the date timestamp to be the same on both sides of the expression when comparing 2 dates.
- Filtering SP list items – You can (and you should) use the regular ODATA conditions (Filter, Top, Order By, Limit Columns) to lower the number of rows retrieved from a SP list.
Note: Expand seems not working so for example you cannot filter a SP list on a column containing a User object referring to the user name.
- Formatting emails – Use HTML tags and force the email type to be HTML otherwise your email might not look like what you entered in the Body field in the flow.
- Renaming steps – Useful for better documentation and labeling but you should be careful when renaming objects in an already functioning flow because it can mess up your conditions. I recommend naming the steps properly when creating the flow from the beginning.
- Dynamic content and expressions – Combine dynamic content inside expressions or just type in some text directly and then use an expression inside it. Expression builder even has a sort of intellisense support which is very convenient.
- Emails can be sent “On behalf” of a shared mailbox – You only need a permission for your account to be able to do that.
Few difficulties with live usage in Prod
Considering a company would want to leverage Flow properly and start building up their flows, there are a few points to keep in mind and look into before starting. Some of them already have a solution but are mentioned here just to make sure they are considered.
- No separate environments for Development, Train and Production. You have just Prod which is not ideal.
- Need to add owners to share flow with a team. This can be done manually or you could build a flow that scans all your other flows and adds a specific owner to them.
- No history of edits is available. There is a possibility to export flow definition and save it in source control but that’s a bit cumbersome.
- No easy (automated) way to document a flow. This might be a pain because you need to use another apps, ie. Visio.
- Not that easy to debug. During development, you often have to create a test flow which you can trigger manually and test out some specific piece of code.
Note: If you are using MS Flow, please check out the Ideas page and vote for the features you’re missing.
Using MS Flow is quite intuitive and easy. You can build useful flows in a short time and then optimize it as you use it. Even though it’s easy to work with, you can create very powerful flows.
As mentioned on several conferences, despite the low amount of advertising from Microsoft, a lot of people see the potential in MS Flow and the whole Power platform. After working with it for some time, I as well believe that we will hear a lot about the Power platform in the near future.
I encourage everyone to try it out and think about the possible use cases. Even if it looks simple or not worth it, just try to count how many minutes you could save every day/month/year and you might be surprised.