Get up-to-date on the latest in SharePoint with our free SharePoint 2019 Server Handbook. Download here!
Have you been busy building Flows so your organization can deal with complex business scenarios? If so, you’ve probably had times when your regular corporate account just doesn’t do the trick.
One scenario that might require you to look beyond your own account is when access may be limited. For example: Suppose you’re building a Flow that needs to capture information for any user and store it in a SharePoint list, but most users can’t access the list. This is where using a Flow service account can come in handy.
Unfortunately, this type of account doesn’t have any special configurations or properties to support specific scenarios for your Flows by default. Here’s a list of some of the key properties it should have for optimal usage.
Microsoft Flow has four license tiers available to users ranging from Flow Free to Flow Plan 2. The monthly cost per users increases as you progress from one tier to the next along with the number of Flow runs allowed per month. Access to special features also increases while the delay flow frequency decreases. Visit the official Flow website to get a fuller picture of what the different tiers of Flow offer.
Organizations that implement Flow service accounts often have many of their complex Flows run under such account due to the faster start times. It also isn’t typically necessary to have more than a few accounts. With that in mind, I’d suggest going with the highest tier licensing if possible.
Security should always be top of mind when dealing with corporate data. Though you may have already implemented specific password rules to reduce the risk of information theft, there are a number of configurations in your Office 365 tenant that can help to further secure your environment. Just be aware that you need to be careful when applying these same rules to the Flow service accounts.
Recently, there have been studies that show that traditional complex eight-character passwords may not be as good at keeping hackers away. Cybersecurity experts, such as those at the National Institute of Standards and Technology (NIST), now suggest that using longer passwords with no special characters may in fact be more secure since they’re harder to crack.
By that same token, it’s no less important that the password is very secure for Flow service accounts. Having a long and complex password is recommended. These passwords should be very carefully protected and only shared with users within your organization.
The same studies that are recommending using longer passwords also show that forcing users to change their passwords on a regular basis can be counterproductive. Trying to remember passwords is tedious, and users may end up electing to go with a simpler password.
When a Flow runs, its actions need to authenticate with an account. Some Flows may stop working properly if a password expires. This can have a detrimental impact on an organization, particularly if the notifications for such failures aren’t immediate and the staff who can deal with such password resets aren’t readily available. For this reason, forcing password expiry on Flow service accounts should be avoided.
Similar to the password expiry policy, multi-factor authentication (MFA) should be avoided for Flow service accounts. Imagine the hassle that would ensue if, each time a Flow ran, someone needed to provide a passcode sent via SMS or otherwise approve a connection.
Flow service accounts are often configured to manage content by performing create, read, update, and write (CRUD) operations on behalf of the users who don’t have permissions to perform these actions directly. However, that doesn’t mean that the Flow service accounts should be global tenant admins or have other elevated permissions beyond what they require. Remember that anyone (including Flow developers) who have access to the Flow service accounts have access to everything that the account can do.
It’s always a good idea to provide some sort of feedback on the execution of a Flow. In the event that a Flow fails, there are three ways to find out about it without anything special in the Flow itself:
Flow History in Browser
Users can review the Flow history through the Microsoft Flow website. This option would require someone with permissions to the account to actively monitor the history for each Flow. This option might not be feasible and would require a browser to be authenticated to access the Flows.
Flow Mobile App
Users can use the Flow mobile app to monitor progress of the Flows. Again, however, this would require admins to be logged onto the Flow service account.
When a Flow fails, owners of the Flow are notified by email about each failure. Flow failure notification emails contain a limited amount of information and may be sent a day or more after the actual failure occurred.
Therefore, it’s best to configure Flows to email an email distribution group that will then deal with these failures. The Flow service account email should also forward emails to the same distribution group, as other important information about the account may appear that would otherwise be missed by the staff who are managing the Flows.
Overall, using Flow service accounts has many benefits for abstracting information and managing access in your Flow environment. Like anything else, though, they need to be carefully configured and managed to be most effective.