Over the past years many SharePointers got used to SharePoint Designer workflows. The SharePoint Designer workflows were connected to SharePoint lists or content types and some event in SharePoint would start the workflow process. Initially the workflow engine was part of SharePoint and later Workflow Manager 1.0 became the new SharePoint 2013 engine that needed to be installed on a separate server. Some of the exiting features wee removed and some new features were introduced by Workflow Manager 1.0 but the product development never really took off as that version 1.0 never changed.
With the introduction of Microsoft Flow it is easy to think that Flow is a replacement for SharePoint Designer workflows. But Flow is a lot more than just a SharePoint Designer workflow.
Like in SharePoint Designer every flow follows the following pattern.
In Flow however a trigger can be an event in started by almost any of the 176 connectors that currently exist. Are you interested to see which application you can already connect into? have a look at the documentation at the following url:
https://docs.microsoft.com/en-us/connectors/
If 176 connectors isn’t enough you can also have custom connectors. Each of these con
nectors makes triggers and/or actions available to the no code workflow solution that Microsoft Flow is.
Additionally you will find many steps that can help you create the logic that you want.
- Add a condition
- Add a switch case
- Add an Apply to each
- Add a scope
- Add a do until
- Add a parallel branch
Have you noticed there is not a bit of SharePoint in any of this and still Flow can replace SharePoint Designer workflows within your organisation too. I would even expect that a lot of your workflows that you have created in other workflow engines (both including SharePoint and excluding SharePoint) could be created using Microsoft Flow. All the SharePoint parts that you will find within Flow are available within a single connector, the SharePoint connector.
Where SharePoint designer offered you all sorts of string functions within its the workflow actions. Flow simply offers those functions outside the connector. So that you can reuse that even if your flow is not related to SharePoint at all. And this is exactly the strength of Microsoft Flow. Start you process with a trigger from a connector and run actions from any connector and glue the connectors together with the logic steps avaialble within Flow.
I would not try replacing SharePoint workflows with Flow.
Flow is tied to user accounts O365 so the logged in user owns the flies they create. SharePoint workflows are user-agnostic making them more suitable for business critical applications.
John, Are you happy for a workflow to make an update to a document or list items and not know that it was you or the workflow making that update? I can see some circumstances where you want to run as the submitter (like with manually started flows). I wouldn’t be surprised if this is something that will be added in the future as there have been requests within the ideas section on the community site.
Hi! Is it cool such tools as Flow exist for individuals. Problem is: in companies you try to industrialize processes, an so you define workflows
to make everybody follow the same road. Process vs freedom, huge debate…
Hi Damien,
For my business processes I use a service account for my flows.
Some people don’t like that if these flows update for example list items in SharePoint, that these items are updated by the service account. But personally I like it that I can recognise my personal updates and system updates by the service account.
Hi Pieter. It is the same for workflows : you can make them run as super admin. Nevertheless you are right, functionnalities in Flow are ok now. May be I just have a problem in my mind: I am used to think Flow is for a personal use, and not to industrialize business processes… Thank you to make me aware of Flow possibilities.