I
Love
Microsoft Flow
I don’t know what it is, but I spend a lot of time in it, from small silly Flows to real time savers. I’ve shared a few of my Flows already, and will be sharing more. I may be a little addicted to automation, Flow being the biggest contender, but also other services like IFTTT and Alexa. I share my addiction in this post, check it out.
Being a developer for the last 20 years or so, I found that many of the best practices in development applies in Flow too! No, you don’t have to be a developer to understand what we’re about to run through.
Name your Actions
“Duh, of course, name your actions…” but do you? When you drop actions into a Flow, you get the standard name of that action.
The title bar of the action is its name (see the blue SP logo above, with the Get items, that’s its name). Why is that important? When you go to use the data from this action later, the dynamic content selector will group its properties by this name. If you’re in a small Flow, this might not be a big deal.
If you’re in a bigger Flow, getting multiple sets of data, this can get unruly quickly:
You might say, “well, they’re unique”, and they are! But down the road, do you know what Get items 3 returns just be reading that title? Here’s what happens in the dynamic content selection:
Renaming it will help you know what data belongs to what. To rename, click the menu for the action and select Rename. Rename it to what the end goal of the action is, what is it doing or returning, for instance, Conferences, List of Contacts, SP Contacts, etc. Just make it unique and important to you.
So let’s rename those actions:
And now later I’m much happier since the dynamic content selection makes sense.
Use Variables
This is a developer thing for sure, but it’ll help the non-developer too. Say you have a Flow with a few conditions, maybe a few parallel actions, and you’re writing similar data across multiple actions, like an email message. Or you have a condition where you’re parsing a string, then you need to use the parsed data again within the condition statements. Variables will be your friend here.
Using a variable, you can set the value of it once, like parse a string or compile a message, and then reuse that variable whenever needed. Anything you may use more than once, set it in a variable.
To do so, add the action Variable – Initialize variable into your flow, set the variable name, type, and set the value! (don’t forget to rename the action)
In this example, I’m setting the task title to the from address and subject line of the incoming email. I am doing this because I create tasks in a few different places, so I want to make sure they all use the same format. Down the road, if I decide to change the task title, I can change it once and it’ll update all the other locations.
Webhooks vs Posting
This will feel very developerish, and it will have some code, but bear with me.
Many data connectors are available in Flow, like Slack and Teams, and they allow for simple posting into their services through these actions.
These are great, but consider using an incoming webhook. This will be a more complex actions, for you as the Flow author, but the benefits are greater. Using an incoming webhook, in most cases, gives you additional customizations to give your posts a cleaner, more professional look. Check out this post on comparing posts to incoming webhooks.
More to come!
There will be more to come, for sure, along with troubleshooting and debugging Flows. If you have a suggestion, please share it below and I’ll spread the word!
‘Til next time, Happy Flowin’!