Microsoft Flow is a user-friendly way to create workflows between line-of-business applications. Introduced in mid-2016, Flow let’s business users create notifications, move data, and automate approvals among popular applications such as Google Drive, SalesForce, DropBox, Twitter, Slack, OneDrive, Dynamics CRM, on-premise data and dozens of other data sources.
I decided to give it a whirl when I had a client request to help automate an out-of-office calendar a few week ago. Ordinarily my first instinct would be to use SharePoint Designer or another workflow builder, but in this case Flow seemed like a good option.
Building a Simple Approval Flow
You don’t have to be a developer to create a Flow. I’m not a developer – far from it, in fact – and I was able to not only grasp the application, but create several Flows in under an hour.
How annoying is it when you put PTO on your Outlook calendar, but inevitably have to put it on a SharePoint calendar, too, just so everyone can see it and it’s properly approved?
Using some of the built in actions in Flow we’re able to automate the creation of the event in the SharePoint site. User puts the request on his or her calendar – Flow creates a new item in SharePoint – Manager gets notification because he or she has alerts set up on the SharePoint list.
I’ve set this flow up in my Office 365 environment and am using my Office 365 Outlook account.
Flow includes dozens of built-in templates to complete simple notification and data and file transfer actions, but after reviewing the template library I didn’t see anything that really met my needs. No problem. I’ll create my own.
Start by clicking the Create from Blank button in the upper right of the Flow application.
Flow is comprised of three key features that work together to create the workflow.
- Services – a list of pre-defined services from which users can call or send data (note: not all services are created equal!)
- Triggers – a list of actions that ‘trigger’ a response (eg. When a list item in SharePoint is modified)
- Actions – a list of subsequent actions to be taken by the workflow depending on various conditions. (eg. send a notification or create an item elsewhere)
In this case we’ll define our Service as Outlook and our Trigger is ‘When a new Event is Created.’ Obviously, we need a condition here, though. Certainly don’t want to create an event on a SharePoint calendar every time an event on my Outlook calendar is created.
We can use Dynamic Content to create conditions based on existing fields in Outlook events. In this case, I’ve set my condition for when the Subject contains CTO. I could put CTO Mexico! Or CTO European Adventure in my subject line – doesn’t matter just needs to contain CTO.
I have my service – Outlook, and my Trigger – anytime I add an event with CTO in the Subject, now I need my Action. Copy the item up to a corresponding SharePoint calendar.
This time I used Dynamic Content to fill in the appropriate data from one list to another. I even added the Display Name column so that my name is appended to the Subject of the event on the SharePoint calendar. This will help my team differentiate between CTO requests.
Since we’ve turned on alerts on this Calendar my manager will now get an alert for my submitted CTO request.
Also, our SharePoint calendar has additional metadata added to it – namely an approval column. My manager can update the approval and I’ll get an email notifying me since an item I created was modified.
In under an hour we took an approval and request process that involves email, double posting and more than one person and streamlined it into a simple Flow.
That was just too easy …
Yeah, well … sort of. A few things to think about before you go Flow-wild.
First, this is a cloud service and it’s dependent on, well, cloud services. The Flows don’t necessarily kick off immediately after an item is created, edited, etc. Flow ‘checks’ every several minutes to see if anything has changed meeting the conditions and then the Flow starts – premium plans allow for more frequent ‘checks’ – but, of course cost more money. At first this frustrated me because I knew I set this thing up correctly and it wasn’t working – on a hunch I gave it a chance, did a bit more research and sure enough in 10 minutes it appeared. Not too shabby if you consider I was on airplane wi-fi 35,000 feet in the air!
Second, like anything these days, Flow is going to require some level of governance. Flow is free and allows licensed users to create up to 750 runs per month (that’s a lot of time-off requests). This means though, that any user can create a flow and which environment users use to create their Flows could become a complicating factor. Administrators control environments and environment creation, but there need to be clear guidelines for when a new environment should be created for users.
Finally, Flow is not going to magically automate all your business processes. I’ve brainstormed a slew of relatively simple processes that I couldn’t quite get to work with Flow – mostly because the Triggers didn’t exist for a lot of applications outside the Microsoft family. Does that mean they won’t in the future? Not necessarily. Flow is in a growth phase – users can submit created Flows at templates to the template library if they think they are general enough to appeal to mass audiences. Not to mention the templates Microsoft is creating. Additionally, developers can use API calls and tie them into Flows. All of this is to say that Flow is in its infancy, (ok maybe it’s a toddler by now?), but it’s not a full-time solution. Can it be? Very possibly? Will it be? Stay tuned.