Microsoft Flow & PowerApps governance explained - Enterprise Social Nederland
Voor organisaties die het maximale uit Enterprise Social willen halen. Zero-email, Sociaal Intranet en Yammer advies, implementatie & adoptie. Dé ESN expert
enterprise-social;enterprise social advies;yammer advies
post-template-default,single,single-post,postid-7999,single-format-standard,ajax_fade,page_not_loaded,,select-theme-ver-3.5,wpb-js-composer js-comp-ver-5.4.5,vc_responsive

Microsoft Flow & PowerApps governance explained

Microsoft Flow & PowerApps have turned into quite important applications in Office 365, but most organizations haven’t set up any governance for them. This post explains how to administer Flow & PowerApps while also embracing the fact that these applications will become even more important in the future. Microsoft Flow is an application for creating workflows and it should be considered as the replacement for SharePoint designer workflows. PowerApps can be used by both developers and IT-pro users to build web-based applications and is the first thing people should look at when there is a need to build an application for Office 365.

The reason why most organizations don’t look into the governance of Flow & PowerApps is because it all works fine and the IT department doesn’t have to set up anything. Governance requires time and it’s working fine without any issues, why would you want to add complexity here when it isn’t needed? Microsoft Flow makes use of the self-service sign up feature. This means that users simply have to visit to create an account by signing in with their Office 365 credentials. They will then end up with a free Flow for Office 365 account. This means that users can completely bypass IT when the self-service sign up feature hasn’t been disabled. Now let’s take a look at one of the templates presented to users after signing up:

The templates are published by Microsoft and the one shown above has been developed by them as well. This Flow template simply synchronizes the Office 365 Outlook calendar to their Google account. It has already been used 25182 times and chances are that people are using this right now in your organization. A lot of organizations have mobile device management in place, but the users can easily bypass this by using Flow to synchronize everything. This is just one of the templates, there are many more that obviously violate data security restrictions that have been put in place in enterprise environments.

Flow allows users to authenticate for different cloud services (i.e. connections) and one can say that users can already develop something like this on their own without using Flow. That is correct, but most users of Flow aren’t developers and there is a difference between someone spending multiple hours to develop something and someone that sets it up with a couple of clicks. You can’t really blame users for doing this when it’s being advertised right there on the homepage.

Flow and PowerApps make use of the same set of connectors. Most of the connectors have been developed by Microsoft and this is rather easy for them to do as cloud services have extensively documented their API’s. Times have changed and without this documentation, Cloud services don’t have a future as they rely on the connectivity with other applications. New connectors are being added several times a week.

You can add restrictions to Flow and PowerApps by making use of Data Loss Prevention policies. The restrictions you put in place will have the same impact on both applications and there is no way to change this. There are some other limitations which we will cover below. One of the things you have to keep in mind is the fact that Flow is considered a free public cloud service by Microsoft. Let’s assume that someone created an account on Flow by signing up with their Office 365 credentials. This doesn’t result in a tile for Flow in the Office 365 app launcher. The only way to prevent the user from making use of Flow with these credentials is by disabling/deleting their account in (Azure) Active Directory. Assigning users a license for Flow also means that there is no way back, removing the license only removes the tile in the app launcher. This is one of the reasons why it’s important to look at the governance of these applications.

To start administrating Flow & PowerApps, you first need a Flow P2 paid license. This allows you to create the DLP policies, but it also gives you the option to create 2 more environments. You also need to assign this account the global admin role or you won’t be able to make changes to the default environment.

You need to visit with the account to reach the administration center. You can also use the admin center of PowerApps, but your changes will be implemented for PowerApps anyway.

Now click on “New environment” in the top right corner. This environment will be excluded from our Data Loss Prevention policies.

Give the environment a name. You could use the name “Unrestricted_Monitored” to make it clear to users when they select it. We will explain why below. You can select the region for storing the Flows and PowerApps. Please make sure to select “production” for the envrionment type or risk losing the environment when the trial ends.

After creating the database, go right ahead and create the database. This will give you some additional features as you probably need to support them in the future.

Now select the currency and the language and you can keep the “include sample apps and data” checked as it won’t have an impact from a security perspective. This just makes it easier for your users to start exploring the features of Flow and PowerApps. Give it some time to provision the database. We can already start looking at the Data Loss Prevention policies.

Now click on “Data policies” in the menu on the left. Now click on “new policy” shown in the top right corner.

You need to select “apply to ALL environments EXCEPT” and check the box next to the environment that we created in the previous step. Flow allows users to start a trial of the P1 and P2 license (you do have the option to disable this, but it will also prevent users from starting a Power BI pro trial). Selecting this option will make sure that the restrictions are applied to these trial environments next to the default environment that most of them are using. We are excluding our new environment because we want to keep the option to give some Flows and PowerApps an exception when this is needed. Now click on “continue” to proceed.

This is where we have to configure the DLP policy. Also note that we can create multiple policies, which is what we recommend doing. You can see two data groups, namely “business data only” & “no business data allowed”. This has to be really clear. These are just labels, the name of the label doesn’t actually mean anything. Adding connectors to the “no business data allowed” data group doesn’t mean that users can’t use these connectors to get access to business data. Users simply can’t combine connectors from the two groups, that’s it. We don’t mind users creating Flows & PowerApps by combining the standard Office 365 connectors, but we don’t want them to combine these connectors with connectors for cloud services we don’t manage (e.g. Google, Twitter, Dropbox etc.). Simply start adding all the standard Office 365 connectors to the top group and leave the other connectors in the bottom group.

As you can see in the screenshot above, there are two OneDrive connectors. We have added the OneDrive for Business connector to the top and have left the consumer version of the connector in the bottom group. This will prevent users from sychronizing their work files to their consumer OneDrive. We recommend not adding Office 365 IT-pro connectors to the top group, but rather creating an additional policy for them where they are added to the top group. Also note that DPL policies are stacked, all restrictions will be enforced.

The reason why we’re creating a separate DLP policy for the Office 365 IT-pro connectors (e.g. SQL Server) is because most users don’t have access to them. This will force users to reach out to the IT-department if they want to create a business application. Users can still create a Flow or PowerApp with any combination of connectors they like, but the Flow or PowerApp won’t work and they will see a notification explaining that the company policies have disabled them.

Now let’s imagine that a user reaches out to the service desk because their Flow doesn’t work. When they are trying to synchronize their Office 365 Outlook to Google calendar, you can simply explain why this isn’t allowed. When they reach out because their business application in PowerApps is not working, this allows you to investigate and determine if an exception should be made. When an exception is required, simply create a new Flow or PowerApp in the Unrestricted_Monitored environment and make them a co-owner. You can do this as your account has a P2 license and you will receive an email notification everytime a change is made to the Flow or PowerApp. The DLP policies are not impacting the Flow and PowerApps int he new environment, but you do need to monitor them every now and then to make sure that they aren’t doing something that they’re not supposed to do. Also note that DLP policies are bi-directional.

Let’s imagine that the marketing department is trying to get data from Twitter to perform sentiment analysis and store everything in SharePoint Online. The DLP policy will prevent this Flow from running regardless of how the information is Flowing between these cloud services. They will probably reach out to the service desk to understand why it’s not working. You need a team of people, including people working for security to join a meeting to hear what they are trying to achieve. After concluding that the Flow is safe, a Flow is created in the unrestricted_monitored environment and the user is made a co-owner.

We also need to deal with the fact that new connectors are being made available on a continous basis. There is a Flow that you can use for this:

This Flow will send an email each day listing the new connectors that have been made available. The DLP policies we have created in a previous step are organic. New connectors are added to DLP policies and there is no way to prevent this from happening. This goes completely against the way IT normally manages applications as you can’t simply disable new connectors by default. By default the new connectors are added to the bottom group, but you can change this to the top group if you want:

Our recommendation is to keep the bottom data group as the default because of the label “no business data allowed”. New connectors will then end up in the bottom group, which means that users can’t combine them in Flows and PowerApps with the connectors in the top group. The problem here is the fact that sometimes Office 365 connectors or Office 365 IT-pro connectors are added. This means that while you are evaluating the connectors, users have some time to combine these new connectors with the connectors in the bottom group. This is why you need to constantly update the DLP policies. When it’s a standard Office 365 connector, simply open the O365 connector DLP policy and add the connector to the top group.

This approach works and will allow users to create the Flows & PowerApps they want, but it will prevent them from easily synchronizing company data to cloud services not managed by your IT department. Every now and then someone reaches out to the service desk, you schedule a meeting to evaluate if it’s something that should be allowed and follow up accordingly. This also means that you don’t have to continously monitor the Flows and PowerApps that have been created in the default environment. You have to keep in mind that users will create a lot of Flows if they haven’t done this already. There is a Flow button in OneDrive for Business and SharePoint Online document libraries. You can disable this button, but this isn’t recommended as SharePoint designer workflows will eventually be deprecated.

The next thing we need to look at is the number of Flow runs. Each type of Flow account gives you a number of Flow runs. The free Flow accounts have their own limit, but the other accounts simply add up to the total number of runs for your tenant. Assigning the Flow for Office 365 license to your users’ accounts will increase the number of Flow runs you have in your tenant. It also adds the tile in the app launcher making the application more accessible. You do need to monitor the Flow runs in your tenant and you might have to reach out to users if they’re making use of too many runs. You can help them to re-design the Flow to make it consume less runs if needed.

There are connectors that can be configured by using both Office 365 credentials or the credentials associated with a free Microsoft account. The recommendation is to create a separate DLP policy for each of these connectors to completely isolate them. This will prevent the users from combining these connectors with any other connector. You can delete the DLP policy when Microsoft decides to split it up into two connectors, one for Office 365 and one for Microsoft accounts (e.g. like the OneDrive connectors highlighted above).

Users that have credentials for other Office 365 environments (e.g. a trial tenant, their personal tenant, the tenant of their employer etc.) can use them as connections in their Flow and PowerApp. You can prevent them from doing this by making use of tenant-to-tenant resctrictions, but keep in mind that this could have an impact on other applications as well. Also note that most users don’t have credentials for other Office 365 tenants and you still have the option to look at their Flows and PowerApps created in the default environment.

The last thing we need to look into are the Flows and PowerApps created by former employees. This is actually our biggest concern when it concerns these applications. The Flows/PowerApps created by former employees will continou to work indefinitely. The Flow admin center doesn’t allow you to search for Flows, which makes it pretty much impossible to find it and stop it from running. We haven’t actually been that restrictive with our DLP policies. We’re not preventing users from synchronizing their OneDrive consumer files with Dropbox as these connectors haven’t been split up between the two data-groups in our policies. We would have to create more than 100 DLP policies if we wanted to isolate the connectors for cloud services the IT department doesn’t manage. What does this mean?

Well, the account you have given a P2 license for Flow has the option to open and edit the Flows that have been created in the default environment. The user has left the organization, which means that it’s now impossible for them to update the Flow or disable it. They would have to reach out to your IT department for this if they don’t have the option to revoke access to Flow by using the admin features of other cloud services they still have access to. This also means that your IT department can simply take ownership of the Flow and add additional steps without the former employee ever finding out. They normally would receive an email notification when you make changes to their Flow, but the O365 account they used is not active anymore.

We encourage our customers to give users a license for both Flow and PowerApps. Our recommendation is to give users a license for Flow if they have a license for SharePoint Online because of the deep integration with these applications. PowerApps isn’t something that all users will dive into, which allows you to be a bit more restrictive. Just give them the license for the free account if they need it. With the DPL policies in place, you don’t have to worry that much about company data being synchronized to cloud services you don’t manage. We have provided our feedback to Microsoft and have asked them to automatically stop Flows from running when the owner has left the company, primarily to protect them from the IT department of the company where they used to work.

We’re not surprised that IT departments haven’t set up any governance for Flow and PowerApps as there are a lot of things you have to consider, but we do think that governance and administration is required and hope that Microsoft starts realizing that the current limitations are not acceptable as they are pushing for more integration with Office 365 applications. Our recommendations for Microsoft are:

  • Create an additional data group for DLP policies named “disabled connectors”. Making this data group the default group should result in new connectors being added to this group and having a “disabled” state. This should be similar to creating a dedicated DLP policy for the connector to prevent users from combining it with any other connector. This will give the IT department time to evaluate new connectors before they decide to include them in the other data groups of the DLP policies. We don’t expect them to do this though as they are probably worried that IT departments simply don’t follow up and severely impact the potential of these applications. We strongly believe that IT departments still should be in control and prefer a too restrictive environment vs an environment without any control/governance

  • Update the Flow admin center a.s.a.p. to allow customers to search for a Flow. This is especially important because of the limitation regarding Flows of former employees. The same feature is there for the PowerApps admin center while it’s actually more important to have this for Flow.

  • Allow customers to disable access to Flow. You can label it as a “free public cloud service”, but you’re making it rather easy for users to start making use of templates that clearly violate security guidelines that have been put in place to limit the risk of losing valuable company data.

  • You need to add Flows and PowerApps to solutions to import them easily in other environments. When you try to import a Flow which isn’t added to a solution, the user has to configure the connections during the import, not after. This means that they either have to share the credentials for these connections or they need to take control of your laptop to enter them during import. We’re happy to see the addition of solutions, but we think that is should also be fixed for standalone Flows and PowerApps. The solutions feature has been created to make it easy to group multiple Flows & PowerApps and easily export/import them, but Flow and PowerApps also support the so-called “disabled state”. Why not allow us to simply import them, make the user a co-owner and ask them to configure the connections and make it work on their own?