06 November 2018

SharePoint Automation with Flow or Workflow?

SharePoint iconIn my previous blog post I showed how to create both flows and workflows that achieve the same thing: automatic SharePoint tasks creation. That was an example on how flows and workflows can be used for the same kind of SharePoint automation, even if they are created in different ways.

There are however important differences between flows and workflows, and you have to consider them when deciding which tool to use for each process automation. Here I will discuss some of these differences.

Why automate at all?
Before we go into the two major Microsoft tools for SharePoint automation, I want to point out why you should automate business processes in the first place. I explain that in more detail in the demo below, but the main reasons are:
  • Accuracy – a flow or workflow always works in the same way.
  • Tracking – process documentation is boring to do manually but easy with a flow/workflow.
  • Speed – even if you include the delay before it runs, the flow/workflow is quicker than humans.

Traditional workflow
SharePoint Designer iconDuring the last ten years, workflows have been the traditional way of automating business processes in all kinds of SharePoint editions, both online and on-premises. Microsoft has given us a few built-in workflows, but other SharePoint workflows are created from scratch in a free designer tool, SharePoint Designer.

Workflows cannot easily connect to apps or services outside the SharePoint site where it is running. There are two versions of SharePoint workflows, 2010 and 2013, but there will not be a 2016 update.

New flow
Microsoft Flow iconAt the beginning of 2016, Microsoft introduced a new service for workflow creation: Flow. This is a cloud based service, and a flow can connect to many other online services. Flows are created on a website, and the SharePoint Online modern interface also gives a possibility to create a flow directly from inside the list or library that you want it to manage.

If you use a flow for a business process, you must be aware that flows are stored in the personal account of the user who created them. Therefore, organizations who want to use Microsoft Flow should use a dedicated account for all flows. Then you can continue using and editing the flow even if a user leaves the organization, and you can also manage potential costs in cases of high volume flows.

In workflows the storage is not a problem, as workflows are stored in SharePoint and not in a user account.

Workflows can start automatically when an item is created or changed, but flows have many more available triggers. This is partly depending on the multitude of services that flows can be used with, but also if you look at SharePoint only there are many more triggers than for workflows.

Microsoft wants Flow to be simple, easy to use automation tool so they offer a multitude of flow templates. Workflows, on the other hand, has no templates at all. Using templates can of course be a good way to start creating flows, but I actually prefer to start with a blank flow. Then I will have a clean flow that does not contain anything but the parameters I add to it.
StorageUser accountSharePoint
ServicesMany cloud basedOnly SharePoint
CreationWebSP Designer
Works after change of list/column nameNoYes
MS DevelopmentYesNo

Name changes
I also want to mention a less obvious issue with flows: if you change the name of a list or column that is monitored by a flow, you must change the name in the flow also. Workflows don't use the names you give to lists or columns. Instead they use the internal name, a GUID, and therefore workflows are not affected by any name changes.

Both flows and workflows have their benefits, and ideally you should learn both to be able to select the best option for each occasion. Flow is the future, but inside SharePoint the workflows are still very useful. In the Tips section you can learn much more about both flows and workflows.

By Peter Kalmström
CEO and Systems Designer Business Solutions