Microsoft Flow is not a Governance solution for Office 365

It’s time to get realistic about the fact that Microsoft Flow is not the right tool for delivering governance in Office 365. Flow is undoubtedly an excellent tool for Citizen Developers to build approval and notification processes. However, the fact remains that Flow itself is ungovernable which makes it entirely unsuitable for managing governance in Office 365.

Unfortunately, there is a lot of confusion caused by the many blog posts detailing how Flow can be used to provision SharePoint Sites and Microsoft Teams. In principle, these blog posts on Flow are great examples of something which can be built but fail to address the suitability for real world application. Therefore, in this post, I will detail a number of the risks with using Flow for governance solutions in Office 365 and consider some of the more suitable alternatives.

Is it that easy to build?

It may be true that after an initial learning curve a non-developer can quickly build multi-step workflow processes far quicker than they could in SharePoint Designer. However, there is no Flow action for complex objects like creating a SharePoint Site, Office 365 Group or Microsoft Team. So then you are faced with either making HTTP requests using an action in Flow or calling out to Azure Functions.

This should be your first alarm bell about using Flow for such solutions, as Microsoft clearly states Flow is a “powerful workflow automation directly in your apps with a no-code approach.” Yet suddenly we are faced with the prospect of code in Flow, or Flow Code as we call it, which requires development knowledge. If you have to resort to Flow Code, then shouldn’t you be developing a proper solution in Azure and ignore Flow altogether?

How much will it cost?

Cost is such an unknown when using Microsoft Flow. Sure you get some flow runs included as part of your Office 365 licensing, but will this be sufficient? The allowance is across all users and could be used up by a frequently running approval process for documents in a SharePoint Team Site. Also, with the free plan, there is a Maximum flow frequency of 15 minutes which could quickly leave users feeling frustrated, waiting for requests to process.  Therefore, you are likely faced with either purchasing a Flow Plan or the costs of additional Flow runs. Can you be confident of your exact usage levels and being able to calculate the costs appropriately?

It’s also important to recognise that Flow licenses are not your only cost. Many solutions we have encountered rely on additional code packaged in something like an Azure Function. Do you have a clear understanding of what this ongoing cost will be?

Finally, there is the demands on specialists time with building such a solution, which could easily involve weeks of development and testing. Whether this is internal resources, contractors or consultancies, this is a cost which must be recognised. So too is the ongoing cost which we look further at when considering support and ongoing change.

What happens if it goes wrong?

Provisioning in Office 365 is not easy, especially when it comes to complex objects like Modern Sites and Teams. How will a solution in Flow manage unexpected errors in Office 365 or delays in certain aspects of provisioning? Also, can a solution built using Flow manage multiple incoming provisioning requests and any throttling imposed by Microsoft?

There are also the practicalities of supporting a provisioning solution using Flow. These range from the cost of internal support resources, useful error logging and the ability to retry failed requests.

How will you manage change?

Anyone who has been using Office 365 for any length of time will understand that the pace of changes has increased. These changes can vary from updates to the Graph API, new capabilities like Hub Sites and entirely new products like Teams. The ability to keep up with this change is a problem for any internally developed provisioning solutions, including those using Flow.

It is not just the change coming from Microsoft which needs to be managed. Organisations change and needs evolve which will lead to new requirements from a provisioning solution.

Owners of Office 365 need to ask whether a provisioning solution using Flow will be flexible enough to cope with the demands of change. Also, what would the costs be of maintaining suitable resources to continue to evolve such a solution.

What are the alternatives?

There are, of course, more appropriate Governance solutions for Office 365 than Flow. Firstly, there is an essential role for good business process and governance programmes led by champions. If you insist on developing solutions in house, then there are many options for developers in the Azure stack.

I would argue that there is a vibrant selection of third-party vendor solutions available for managing governance in Office 365. These solutions, including ProvisionPoint 365, are clear about their costs, can be deployed immediately, will be regularly updated and fully supported. They are a tailor-made, simple solution delivered by skilled professionals, for what would otherwise be an unnecessary waste of valuable time and resources and an inappropriate use of Flow.