In-Depth

How To Secure SharePoint Online Workflows with Microsoft Flow

Microsoft Flow provides SharePoint Online with more robust and reliable workflows than BCS, and the new administrative tool ensures they're in compliance with your organization's data loss prevention policies if you take the following steps.

• By Oliver Wirkus
• 08/22/2017

When Microsoft released the first version of SharePoint Online as a part of Office 365, many organizations saw the potential benefits of moving the collaboration platform to the cloud.  However, many have balked because it lacked viable connectors to external systems. The only option was its Business Connectivity Service (BCS) but it was cubersome to configure and not reliable and robust, especially when used with worklows. Even though there are some workflow engines available which provide support to connect SharePoint online with external systems, only few companies have used them to connect their SharePoint Online environments with third-party systems because of concerns about additioinal costs and concerns that it lacked certain security controls. The secuirty issues were particularly an issue because organizations need to ensure particpants in a workflow process are all authorized to access infomration that's routed to them.

Microsoft addressed those issues last fall with the introduction of Flow, allowing companies to connect their SharePoint Online environments with a variety of external systems. Like other workflow engines, Microsoft Flow is based on actions that users can stick together like Lego bricks to create a custom workflow. Flow extends that approach by offering non-proprietary connectors to a huge amount of external systems that can be used by Flow actions to communicate with those systems. Microsoft published very detailed documentation to enable developers to create custom connectors or custom workflow actions and the community is gratefully adding new connectors and actions consistently.

Microsoft's intent is entirely clear: Flow lets organizations connect their SharePoint Online environments in a secure and professional manner with external systems to increase business value. The number of connectors has grown this summer, with 159 as of late August including Box, DocuSign, Dropbox, Facebook, GoToMeeting, IBM DB2, Gmail, Google Calendar, Mailchimp, GitHub, Oracle, Salesforce, Slack, Twitter, Wordpress, YouTube and Zendesk (see Figure 1). A complete list is avaiable here.

One of the major benefits of Flow is, it reduces those distracting context switches a user needs to perform when a company's business process spans multiple services. With Flow and its connectors, workflows can be built that can exchange data with external systems without further user interaction. This is much more efficient and less error-prone compared to executing the workflows steps manually and ensures that corporate governance and security guidelines are followed.

Let's take the general vacation-request workflow as an example. A Flow based workflow would be able to update the remaining days of vacation after a vacation request has been approved in an external system without further manual intervention.

Although Microsoft Flow offers additional benefits for organizations, many customers are hesitant to use it. The reason why many are completely restricting the use of Flow is understandable. Microsoft Flow not only provides a way to connect with external services but to exchange data with external services as well. For organizations, it is crucial to protect their data from being shared with external systems in an uncontrollable and insecure way. This is the primary reason many organizations have restricted the use of Microsoft Flow within their SharePoint Online environment, although, many of them are clearly seeing the benefits of connecting their SharePoint Online environment with external line of business systems (like Dynamics 365, Informix, ZenDesk or Salesforce -- just to name a few).

Microsoft is well aware of those concerns, and that's the reason why they added a Flow Admin center to Office 365. With the Flow admin center, an admin is able to create data loss prevention policies to control which external services can be used as a part of a Flow-based workflow.

To create a new data loss prevention policy, an admin needs to navigate to the Flow admin center in Office 365 and click on "Data policies" in the left navigation pane. Here the button to create a new policy can be found in the upper right corner.

The first step in creating a new data loss prevention policy is to define the "environment" that the new policy should apply to. A Flow environment is a group of employees that are pooled together (like HR members or a sales team), almost comparable to a security group in SharePoint.

After the admin has selected the environment that the new policy should apply to, a click on "Continue" will bring the admin to step 2 of the policy creation process.

In step 2, the connectors can be selected that the chosen environment is allowed to use when creating a new Flow-based workflow. The default setting is that no connectors are authorized to be used. The Flow admin needs to allow one or more connectors explicitly.

After all approved connectors have been selected, the new data loss prevention rule can be saved and is in effect almost instantaneously.

Let's switch to a user now and see how this looks for users who intend to create a new Flow-based workflow. If a user is adding an action to a new Flow which is based on an unauthorized connector, this can be done without any difficulty, but as soon as this user tries to save the new workflow, a warning shows up at the top of the edit screen (see Figure 3).

In other words: Microsoft Flow allows creating a workflow which uses any of the available connectors. However, as soon as the Flow-based workflow is about to be saved, it is checked against the data loss prevention rules defined in the Flow admin center. As the message shows, the newly created Flow was saved and will appear in the list of Flows for the current user, but cannot be executed because it has been suspended (see Figure 4).

If the current user tries to turn on this Flow, it is checked against the data loss prevention rules again. If it still conflicts with at least one of the DLP rules, an error message displays.

Compared to the DLP rules an admin can create in the Security & Compliance center of Office 365, the DLP policies in Microsoft Flow work differently. Where Office 365 is able to check for sensitive information like Credit Card numbers, the DLP rules in Microsoft Flow can be used to provide permission to use specific connectors to a particular group of users (called "environments").

Although the data loss prevention rules in Microsoft Flow do not appear to be as robust as the data loss prevention rules in Office 365, they can be used to secure the usage of Flow in an enterprise environment dramatically. At the beginning of 2017, Microsoft had announced that they will be unifying the DLP policy creation capabilities under the Office 365 Security & Compliance Center. As part of this process, I'm hoping that Microsoft will include Flow actions into the powerful data loss prevention policy rules as this would add additional benefits regarding security and compliance to Microsoft Flow. Admins would be able to selectively allow specific connectors to be used by a particular group of users ("environment"). In addition, the data that a Flow-based workflow is transferring to external systems could be checked against the Office 365 DLP policies to ensure that Flow isn't transferring sensitive data to external systems.

As a senior consultant and MVP, I usually encourage our clients to at least consider Microsoft Flow as I believe that Flow is an excellent addition to the Office 365 family of applications that allows spanning workflows across multiple systems. With enhanced DLP rules, Microsoft Flow would become the tool of choice for organizations to connect their SharePoint environment to external systems and increase business benefits and user experience.