For the non-technical Senior Manager.
A blog by Martin Erasmuson.
Introduction
In my first Taming Microsoft blog I described how at first glance, Office365 and SharePoint on-line look pretty similar to your current on-premise environment. We discussed that at the heart of Microsoft’s new strategy is the notion of ‘Self-Service’ i.e. if a user wants something; anything! they can create, enable, share or download it by themselves.
Microsoft Flow, the subject of this blog, is deployed using the same self-service approach. I’ll step through the key risks and benefits of Flow along with a recommended deployment and Governance model which I believe gives you all; or most of the advantages of Flow while mitigating the key risks.
Flow comes free to users with an Office365 account. It’s a cloud-based ‘app’ that allows a user to create; all by themselves, many different types of ‘workflows’ without having to go through your Service-Desk, your IM Team or pesky developers. At first telling this sounds fantastic. But like a toddlers birthday party absent adult supervision, things can go south rather quickly.
Note that Microsoft rebranded ‘Flow’ to ‘Power Automate’ in November 2019. I wrestled with using the new name in this blog but decided to stick with ‘Flow’ as readers will be more accustomed to this term, however ‘Power Automate’ may well come up in conversations you have with your technical folk so in reading this just think ‘a rose by another name’.
As with my first blog in the Taming Office365 Series; if you can tolerate some Microsoft ‘Kool-Aid’, you might consider watching this two minute YouTube clip on Flow (Power Automate!). While this is a very high-level overview, it will give you some context for the rest of this blog.
Flow in a nutshell
This is just a once-over lightly regards what Flow is and what is and does. There are plenty of other web resources including the linked YouTube intro above for any reader wanting more of that.
The basics:
Creating a Flow
Much like other functions in the Microsoft stack, a user can create a Flow from multiple places including right-clicking on a document or from a SharePoint homebage.
Flow Triggers
There are three ways a Flow can be started (triggered):
Automated: A flow that is triggered automatically by some event in the wider system e.g. an email arrives in an in-box (Flow messages you), or a file you are interested in changes (someone edits a document and Flow emails or messages you), or a new file is uploaded to a Library (someone loads a new document to a Document Library in SharePoint and Flow emails or messages you) and loads more
Manual: A flow that is triggered manually by a user – a user can do this from several places in Office365/SharePoint
Scheduled: A Flow that is triggered at a set date/time, either once or as a recurring action
Integration
There are over 200 connectors available for Flow. Flow connectors allow you to integrate your Flow with other cloud applications (Google Drive, Instagram, Jira etc) and ‘some’ of your on-premise, non-Microsoft applications. Unsurprisingly, while most connectors are Free, other ‘premium’ connectors are licensed. More on that later.
Flow - The Dark Side
So far so good Martin. This all sounds fantastic. But buckle-in, turbulence ahead!
Workflow-Lust
What are the risks around self-service, Office365 and specifically Flow? Microsoft’s current self-service approach is not new, and neither are the issues such an approach creates in the form of Technical Debt. Back in the early 1990’s, as Personal Computers moved to the desktop the data quickly followed. Back then DIY-folk, with only basic technical ability could create an Access Database for anything and everything; and they did! On the back of that database-lust, silos of systems and data proliferated on every departmental server, and on every desktop. While IT still maintained the enterprise applications and their databases, they had no clue regards who had copied that core data, who had created new data, who was making copies of the copies, what it was being used for; how, when or if it was being updated. What started as just a few home-built applications evolved into a labyrinth of Microsoft Access Information Webs. On the back of that, nearly three decades late, many organisations are managing significant Technical Debt and associated risk around MS Access-based, system-critical applications with no documentation or support. Many report they are still trying to clean up the mess. (for a more in-depth, albeit tongue-in-cheek read regards Microsoft Access and ‘Commitment-Creep’, see my blog here).
Cross-out ‘Access’ and write-in ‘Flow’ and you have the potential for the same situation today i.e. ‘Workflow-Lust’. It starts off all innocent but with a lack of oversight and loads of ‘Workflow-Lust’, you end up with a labrynth of undocumented, business-critical processes.
The key issues
Where’s Wally? Flows created by an individual user (Wally) are associated with their Microsoft account i.e. wally@acme.com. With the standard Microsoft365 License, when an account is inactive for more than 30 days (from vacation or exit) their account is deactivated. This potentially impacts the Flows operations and supporting it.
Business Critical Flows: As described with Microsoft Access in the 90’s, what starts off as a simple Flow evolves into a Business-Critical process, all created by an individual (see ‘Where’s Wally’ above).
Security and cost: Earlier we discussed the 200-plus connectors available for Flow including capability for integration with on-premise data. On the face of it, that sounds great, but users can purchase and use fee-based ‘premium’ connectors with the potential to use and store (Google Drive), sensitive or confidential information.
What alternative to Flow?
Within Office365, functionality is often duplicated across different parts of the wider architectural stack, and workflow capability is no different as both Flow and LogicApps offer workflow capability.
LogicApps is just one of several Microsoft Azure Cloud Services, along with: DevOps, Virtual Machines, Active Directory (AAD), Application Programme Interface (API) Management, Backup and Site Recovery to name a few. To us mere-mortals, that all sounds fairly important so suffice to say, Azure Cloud Services (ACS) is very much ‘inside the Microsoft sausage factory’ where much of the Technomagic gets done by your heavy-lifting IT Team. Unsurprisingly, most organisations don’t allow civilians to wander around in ACS, limiting access to just a few administrators and the like. Flow on the other hand is available to any licensed 365 user in keeping with the Microsoft Self-Service approach.
And there, as Shakespeare put it in Hamlet, is the rub; “To LogicApps or to Flow; THAT is the question”? i.e. which of your organisations Office365/SharePoint processes should be built in managed/secure LogicApps, and which in no-holds-barred Flow?
Integration vs Automation
The general rule of thumb is: use LogicApps for Integration, and Flow for Automation; LogicApps for Business-Critical stuff, Flow for personal productivity. If I were comparing LogicApps and Flow in a home renovation example, I’d describe Flow as the DIY/home-handy-person capability and LogicApps as the expert/tradesperson/industrial-strength expertise. And this is kind of a clue regards how I’d suggest they are managed (Governance).
Heaving-lifting Integration with LogicApps
Managed connectors are deployed and managed by Microsoft to provide a bunch of triggers and actions for accessing cloud services and/or on-premises systems including built-in triggers; Manage or manipulate data (create, append, join); Managed API connectors (FTP [File Transfer Protocol]; Salesforce); On-premises connectors (for IBM DB2, MySQL, Oracle, Postgre); Integration account connectors (Flat File Encoding, EML Transformations) and Enterprise connectors (for IBM/SAP). I only include all those to reinforce LogicApps heavy-lifting capability.
While LogicApps is also capable of more simple, non-critical automations, that would be using a sledgehammer to crack a walnut. Leave the mundane, non-critical stuff to the ‘nut-cracker’ that is Flow. LogicApps’ real value is in integrating disparate, business-critical systems across your organisation and having those workflows managed and supported by appropriately experienced staff, just like you likely do now with your other business-critical systems (financials, asset management etc.).
Personal Productivity with Flow
The flip side of the above is allowing users to build their own Flows to automate repetitive tasks and support personal productivity i.e. text me if an email arrives from wally@acme.com.
Decision Assessment Criteria
Below is a simple table I developed to work out when to use LogicApps and when to use Flow. I don’t see this as definitive, indeed I’d encourage the reader to use this a a starting point and develop your own criteria. In this regard, I’d welcome feedback.
Governance and Reporting
Disable Connectors
For many Public Sector agencies, several connectors will just reek of trouble. Google Drive springs to mind. I recommend developing some initial opportunity/cost/risk criteria with appropriate IM, Risk and IT staff; and using these, complete a fist pass of connectors with the view to removing problem from the off; remembering these connectors will still be available for workflows developed and supported in LogicApps. In this approach we are basically taking the scissors off the children before someone gets hurt! Indeed, the US Federal Risk and Authorization Management Program (FedRAMP) has done a similar thing.
This will likely be a ‘rinse and repeat’ exercise insomuch as Microsoft will be continually adding connectors and/or you miss one of the problem connectors in the first pass. Your reporting can support identifying these.
Reporting
MS offers some great OOTB reporting with numbers, graphs and dashboards. Earlier I introduced the concept of ‘Workflow-Lust’. There is the potential here for ‘Reporting-Lust’ i.e. creating/running a bunch of reports just because you can.
I prefer a reporting framework approach (right):
what are your objectives (for off365 and workflow)?
ID the KPI
Report on those
Analyze what the reporting is telling you
Example: Having decided that certain connectors (e.g. IBM , MySQL) will only be used in LogivApps workflows, doesn’t mean a user doesn’t work out how to integrate one into their personal Flow. A report then would ‘id’ use of ‘flagged’ connectors in Flow.
Conclusion
The wider Microsoft Office365 capability offers some extraordinary opportunities with some equal measure of risk. As I suggested in my first Taming365 blog on Teams, you can pretty much have your cake and eat it; exploit almost all the capability with some lite-governance over the key areas of risk.
Good luck!
Your comments and feedback are welcome.