Microsoft Flow is a cloud-based platform for business process automation, which allows an Office 365 tenant user to build elaborate workflows and integrate numerous sources using connectors to Office 365, Azure, third-party vendor platforms,  gateways to on premises servers, as well as custom connectors or HTTP requests to virtually any external service.

In this article we will focus on its ability to replace legacy SharePoint Designer workflows. As a proof of concept we migrate a  SharePoint Designer 2013 approval workflow to MS Flow and highlight the key differences and challenges.

The SP 2013 solution

The solution has the following main components

• a SharePoint custom list allowing end-users to create an expense request for approval to the management
• a Sharepoint Designer 2013 workflow, triggered by the “on create” event
• a SharePoint workflow task list, and two custom content types, “Approval task” with actions Approve/Reject/Rework and “Rework task” with actions Cancel/Resubmit
• a SharePoint custom list of “Executive approvers” who are the final approvers in the approval flow

A request  submitted  by a user contains general information about the request (title, ID, description, amount) as well as approvers designated by the requester (like his general manager, local unit manager…). Some of the designated approvers are optional.

Every request passes sequentially through up to 6 approvers before it gets approved.

• Whenever an approver rejects a request, the request gets the status “rejected” and the workflow ends.
• If all approvers approve an item, the request gets the status “approved” and the workflow ends.
• If one of the approvers requests a rework, the user has the ability to cancel his request or rework it. In the last case the approval starts all over again to approver 1.

The requester gets an e-mail confirming whether his request has been accepted or rejected and a task if his request needs rework. All tasks also trigger a mail alert by default to their assignee.

The main building block of the workflow is a loop which goes through all the approvers, assigns a task to each, waits for the result, and if the results is not “approved” it breaks the loop to step into the alternate stages.

The MS Flow solution

In MS Flow our solution contains these components

• a flow with the main business logic
• some variables
• connections to services, in our case SharePoint Online and Outlook Online
• actions on SharePoint Online and Outlook Online
• a trigger from SharePoint Online

Editing

Editing a workflow in MS Flow is simply a matter of going to the MS Flow app under the O365 app launcher and switching a flow to edit mode. No need to install an app or plugin, the environment is also fully compatible with all current browsers.

The user interface is slick and fluid, yet there are some limitations at this time, here are some we experienced:

• When you create a flow with a lot of switch/case or parallel conditions, the graphical representation becomes quite wide (zooming in/out with your browser can help), and it becomes cumbersome to move horizontally between portions of the flows, also the browser doesn’t always get it right when to display the scroll bar.
• Text fields (like mail body fields) trigger an interpretation of your keystrokes, and this can cause some delays, typos and/or mess up your text when mixing static and dynamic values. Also some fields support HTML encoding and some not, which is not clearly documented or indicated.
• There is no way to copy paste, both within a flow, nor between flows, you can however do a “save as” and continue working on a copy. Also you could in theory export a package and then copy a part of its code which is stored in a JSON file format.
• There is a lack of help or guidance when entering an expression, the documentation on this topic is rather basic, so you end up doing a mixture of searching on the web (check the links section) and some trial and error attempts.
• Specifically for SharePoint, when updating an item in a list you are forced to provide all data for required fields, there is no action to update a single field. Also the integration of MS Flow solutions in SharePoint is limited, in the modern experience the Flow features are simply links to the Flow environment, there is no integrated interface for managing or manually starting workflows like SP 2013 workflows.

For keeping an overview of a long workflow, a good practice is to group as much as possible actions together with “scopes” (grouping actions) with a distinctive name. There is also the possibility to comment your code in every action.

Some tips if you plan to work with SharePoint (custom) lists:

• When you make changes to the (list) content type, these changes are never directly reflected in MS Flow, not by re-selecting the list in the SP actions, not by switching edit mode on and off; you need to close your flow, then in the flow overview page (where you see the run history, connections, owners, …) go back to editing, you’ll see the changes.
• If you use a lookup field in a list where you want to update items, it will report a failure on update if you use “Title (linked to item)”; curiously the issue doesn’t occur when creating an item, and even while it reports a failure it actually successfully updates the item (but can cause your flow to stop). If you want to avoid the failure report use plain Title or any other field.

Triggers and overall logical buildup

The starting point for every workflow in MS Flow is a “trigger”, an action initiating the workflow, this can be any event coming from any connected service that you can subscribe to. Alternatively, this can be a schedule executing the flow on a defined frequency.

In our case we want to start the workflow whenever a new item is created in the SharePoint request list, but also when an item needs a rework.
In SP 2013 we would use the “on created” event, if the requester asks to resubmit, the workflow can simply go back to the initial step without the need to restart.
However MS Flow has no “go to” or “go back” so we need the be able to capture the “on update” event as well. So in the case of a resubmit, the request gets updated by the flow and a this triggers a new execution of the flow on the request.

Be aware that capturing a larger scope of events (both creates AND updates) has an impact on the quota of runs allowed in your MS Flow plan. As of writing of this article, the free plan of Flow that comes with O365 enterprise licenses allows up to 750 runs per user or 2000 per tenant. Above that amount of runs you’ll need a paid plan. Check the link section below for more information. Also note there is currently no way to detect the number of runs in the free plan (other than by noticing when a run fails, or by downloading the run history).

As we initially used the “Create” trigger, at some point we needed to change it into the “Create and update” trigger. In SP 2013 you can simply check or uncheck the different startup options (manual, on create, on update). A current limitation of MS Flow is that you can’t easily change a trigger. As soon as you are using data from your trigger in your workflow, your trigger is implicitly attached to your flow and it can’t be removed and replaced. The editing menu of your trigger will show this message:

The reason is: as other actions in your flow depend on its input, the flow would break. If your new trigger uses the same connection and you don’t want to recreate the full flow from scratch, there is a workaround:

• export the workflow as a zip package (option “create as new”)
• make sure to rename the original workflow to avoid conflicts when importing
• unzip the package file, look for the definition.json file
• replace the trigger by editing the file:
  in our case we replaced “When_an_item_is_created” with “When_an_item_is_created_or_modified” , “GetOnNewItems” with “GetOnUpdatedItems” and “onnewitems” with “onupdateditems”
• recreate the zipfile (make sure the Microsoft.Flow folder is in the root of the zip file
• import the package, the flow is now triggered by the new action

Variables

Since the user has the ability to edit his request during the flow (and our approval process can take up to 3 or 4 weeks), we first store all the request data into variables that we’ll use during the flow. This way we avoid that the data changes during the flow execution.

Also we can store some tenant related data like an url of the site collection in one place instead of in all the the connector actions that depend on it. If we move the flow later to a different environment (eg. from test to production) we only need to change a few variables.

Finally, storing the most important data in variables has the benefit of  having them suggested as first when entering dynamic data, so you don’t need to scroll or search in a lengthy list of data from all the connections and actions.

Approval

Approval in MS Flow is accomplished either by Approval Tasks or Approval Mails.

Approval Tasks reside in the MS Flow itself and are visible under the Approvals tab.

When you use the “Start an approval” action, it adds an entry in this list and generates a mail notification to the assignee.

There is however a significant limitation at the time of writing, you cannot customize the list of actions, it is limited to Approve and Reject.

So for our case, as we needed Approve/Reject/Rework and Resubmit/Cancle, we decided to use the “Send an Approval Mail” action, which sends a mail with the customized list of actions included as link button. When clicking on one of the buttons, the approver is directed to an Azure page which sends the selected action to the flow (once an action has been activated, you cannot trigger the same or another action).

There is a drawback and an advantage to this action: if you include all relevant data in the approval mail, the approver doesn’t need to leave his mail environment to asses the request and perform the appropriate action, this in replacement of the SP 2013 approval experience, where the user has to click on the link to the item, edit it, select an action and save the item (or click on an action button). Replacing all these steps with a single click is an appreciable improvement in terms of user experience.

The drawback is that you have no trace of the approval that are open, nor in Flow nor in SharePoint, so we ended up building a feature into our flow, which adds approval “reminders” in a custom list.We cannot include however the actions from the mail into this list, so the mail is the single point of failure for the process. In our case there are no external mailboxes or -environments involved so the risk is rather limited.

Tracing

There is no tracing feature builtin MS Flow, so you’ll have to use either an 0365 repository (custom list) to trace your actions from within Flow, or for a more enterprise solution store all traces in Azure Service Bus where they can be processed by any subscribing service.

User Account

A final note on the user account running the flow. You can have different accounts for the main flow and the connectors, so your flow identity and the one sending mail for instance can be different. It is however advised to use a service account for the execution of the flow, be aware that it will the necessary permissions to carry all the required actions in SharePoint and Outlook, as well as the licences to access those services.

Also if you plan to protect your user account with Multi Factor Authentication, there is no way to use an app password in Flow so you’ll end up having to refresh the authentication token on a frequent basis in the Connectors tab. If you have any connection failure frequently causing a flow to stop, MFA might be the cause.

Conclusion

With MS Flow now for over a year in GA release, we can conclude that it is a more than valid option to migrate your workflow to.

However, before moving an existing SharePoint workflow to this platform, we recommend to list your main business requirements (the “must haves”) and check these with a proof of concept. It will also help familiarize your customer with the way MS Flow works, since it is not part of the SharePoint stack, things like approval look different and and are managed out of the SharePoint environment, so it is better to make him aware upfront of the changes in the user experience.

Pros

In our  experience it looks more reliable and certainly faster than the SP 2013 workflow engine.

The learning curve is fairly shallow, with exception of the (advanced) expressions. The general buildup is and user interface is very intuitive. the community is now large enough to provide you will kinds of help.

There is virtually no limit to the possibilities of MS Flow when you start expanding in a platform like Azure functions, Web API, Azure automation, or extending it as a Logic Apps solution in Visual Studio.

With Connections (shared with another 0365 service called PowerApps) it is clearly becoming one of the key components of the 0365 environment, and “the way to go” for any workflow based solution in the Microsoft cloud.

Cons

The user interface has some issues especially for “long” and “wide” workflows, long text fields, it offers no ability to quickly copy paste or change your trigger …

The inability to group logic in steps and navigating up/down between these can be an issue for more complex workflows.

Custom tracing is (not yet) available.

The actions of the SharePoint connector have different (often more limited) possibilities than their SP Designer counterparts, always take that into consideration with a proof of concept; you can always workaround these limitations with SharePoint REST API calls or Azure functions but you’ll need to assess the complexity and effort of these workarounds. As the platform constantly evolves, it might be an unnecessary investment in a few months time.

Links

MS Flow pricing

https://emea.flow.microsoft.com/en-us/pricing/

O365 Power Users Forums

https://powerusers.microsoft.com

0365 UserVoice

https://office365.uservoice.com/

Flow will let you automate business processes based on the connectors for services that are available. You can start building a flow from scratch, or you can start by using one of the many predefined template. For creating one yourself, all you need is a modern browser. At this moment, there are around 100 services that can be used by Flow. A list of all services can be found at the following location: https://flow.microsoft.com/en-us/services.

PowerApps on the other hand is an enterprise service for building business apps which can be created without writing code and have the possibility to be connected with different data sources, connectors and gateways. These apps can be shared throughout the company and can be used on different environments and devices. You can access the PowerApps via a modern browser, or via the apps for Windows 10, IOS or Android. The apps you created will be visible in an overview on your own PowerApp page and in the SharePoint list as a view. A PowerApp can be created in the PowerApps studio for web or Windows. This means you have the possibility to develop your business apps online, on the web or dedicated on your Windows machine.

Managing PowerApps and Flow however still has its flaws. To start off, every user who has access to PowerApps can create an app. As an administrator, it’s not possible to check how many apps currently are developed and used. However, there is an admin center available (https://admin.powerapps.com and https://admin.flow.microsoft.com) with some other administration tools. Unfortunately, the only parts you can manage (at this time) are environments and data policies which we will dive in briefly.

Environments

Environments are used as a space to store, manage and share the apps, flows and business data from your organization. You may choose to create separate environments for development, test and production, or you can choose to just create one environment for everything. If you choose to splits up your environments, this will impact the development of your app because the resources which are put in an environment are only accessible to the other entities within the resources and are bound to the geographic location of the selected datacentre. So, if you create an app in the environments ‘test’, it will be able to access the data sources from the test environment, but not from the production environment. Within the environment there are two roles defined, an Environment Admin and an Environment Maker. Global administrators can also manage all environments that have been created in their tenant and set tenant-wide policies from the PowerApps admin center.

Data Loss Prevention (DLP)

Data loss prevention policies are used to protect the business data of a company. In short
it will guarantee that an app which has no rights to share the data, will not be able to so with the company data within their PowerApps of Flows. When adding a DLP, a service can be added to the list which will block exploiting the data from the selected service. A list of all connections possible for PowerApps can be found here: https://powerapps.microsoft.com/en-us/tutorials/connections-list. These limitations can be very useful as the users is probably working with live data.

Conclusion

As stated, these settings are applicable on both Microsoft PowerApps and Flow. So basically, there is no real way of managing and governing the flows and apps created by users except for the possibility to restrict it. This is no surprise because it’s Microsoft’s vision on these tools. Microsoft has built these tools for power users, and so the flows and apps a user creates are bound to the user account. A drawback of this, is that if a user creates and shares an app or flow, but the account of that user gets disabled or deleted in the future, the shared apps and flows will be lost, regardless if other users still use the shared apps and flows. These are things to keep in mind if you decide to use these tools. Be aware that these products are still in preview! Let’s hope Microsoft will expand the managing features in the future to make governance easier, so these tools can be used in a real production environment.