Flow Ownership and SharePoint - Best practices

[dgillespie]

Just getting started with Flow in our company and before a few of us make a ton of them, I'd like to know the best practices when it comes to SharePoint.  A typical scenario would be:

1. UserA makes a flow which requires certain permissions on SP doc libraries and lists
2. UserA leaves company
3. Ownership of flow changes to new hire UserB
4. Flow won't run because of permissions

So UserB will not always get the same permissions that UserA had.  What are the best practices then?

• create an office 365 account just for making flows?  This user would have to have a lot of SP permissions then!
• redo the flows with UserB in mind?

Thanks for you help!

[v-monli-msft]

Hi @dgillespie,

It seems that there is no easy way to solve this issue. The 2 ways you told are all the way I could think of to solve this. I think the first one would be the better way as this will avoid the following issue that if UserB also left later.

Sorry for the inconvenience.

Regards,

Mona

[sergeluca]

we create a dedicated account (we call that a "Flow service account")

[Mike2500]

Permissions in SharePoint are often handled via groups. In that case, if UserB is simply put into the same groups as UserA, then the transfer should work fine. If UserB shouldn't have the same permissions as UserA, then why are they getting the ownership of the Flow? Perhaps the concern is that there are multliple flows, at which point each flow should be reviewed to determine if it should be kept or transferred. Of course, this is a huge challenge as there's no way to know which flows are the mission critical flows vs flows that were created as an experiment, unless each flow is reviewed by a knowledgable user.

It's been mentioned here and elsewhere to use a service account. This sounds good, but there seems to be a lot of permissions issues with this:

1. Do we give users the username/pwd of the service account? I hope not, as this would violate best practices for accounts

2. Do we have an admin switch the connections to use the service account? Sounds good, but then the user could go back, modify the flow, and via that connection they then have access to content in libraries they normally wouldn't have access.

Or, perhaps having to do anything means that the IT dept has already failed, as perhaps mission critical flows should have been recreated as a logic app and deployed to Azure, which brings other benefits such as proper source control.

[dgillespie]

Thank you for the reply.  There may be an issue with logging in as the Service Account to create the flows.

So the administration may look like this?

1. Flow Service account, UserA, UserB are all in same SP group
2. FlowA is created by UserA and also owned by Flow Service Account and UserB
3. UserA leaves and his/her account is deleted
4. FlowA still works?

[Mike2500]

My understanding is that the flow will still run. (this is pretty critical info, I wish the docs were clear). However: if the workflow connected to a SharePoint list, for example, then the flow will have a data connection for that list. If the data connection is using UserA's credentials, then the flow will fail because UserA no longer has permission to the SharePoint list.

So there are two questions:

1. who owns the flow?

2. what accounts are used in the data connections in the flow?

#1 Doesn't seem to be the critical piece, as again, I think the flow will still run even if the owner left. We just need to transfer ownership for maintenance reasons. (please double-check me on this).

#2 is critical, as if a user's account is disabled/deleted, then any data connection using that account should immediately fail the very next time the flow is run. (At which point, a different owner will need to sign in to flow and modify the data connections to use a different account).

So in your scenario, there's not enough info to know if the flow will work. It's my understanding that the flow will try to run, but if UserA created a connection using their own credentials, then the flow will fail on that step due to their account being disabled/deleted.

So, another scenario is that UserA could create a flow, and then when connecting to a SharePoint list in the flow, they could use the credentials of a service account. When UserA left, the flow would continue to run, as the credentials for the list are still good. (But again, giving users a username/password of a different account is not a best practice)

[dgillespie]

Yes, Mike, this gets to the detail of the issue: what account to use for the SP connector?  Using the Flow Service account seems to be the best practice but you are right about sharing credentials; also, the user would always have to make sure he/she was logged in as the Flow Service Account. 

Either way, it seems like a lot of manual administration here: keeping track of who has access to the Flow Service Account, changing the password when a member user left, and what about setting up a Flow Service account per dept.?

[Mike2500]

The user doesn't have to be logged in as that account, per se, as they can specify whichever credentials when they create the data connection. So, UserA logs into Flow.microsoft.com, and they create a flow (which means that UserA is the Owner).When they connect to SharePoint, the connection might default to use their account, but they could just click a little drop-down menu and select to use a different set of credentials, at which point they could enter the username/pwd of the service account.

I certainly agree that any system is going to be a hassle. Even having a service account isn't necessarily better than just having the new owner sign in and update the credentials. The non-service account method also has the benefit of getting someone from the dept to look at the flows and get rid of unnecessary ones. While flows that use service accounts will always run successfully, the downside is that they will keep running successfully for years, even when they're no longer needed or useful.

In my first reply, I mentioned logic apps. To bring that subject up again, if you check out Microsoft's guidance around this, they clearly state that Flow is for "Self-service", while Logic Apps are for "Mission Critical" scenarios.  And, one can take an existing flow, export it as a logic app and then import it into the azure service.

So, perhaps the workable scenario is that UserA leaves, and ManagerA compains that UserA's flow is failing. IT then converts UserA's flow to a Logic App and configures it to run via a service account. No further issues are experienced with that particular flow.

After all, another scenario is that ownership is given to UserB, who goes to update the Flow, but doesn't really know how to use flow, and in the process they break the flow. Since Flow has no undo capabilities and no version history, UserB calls IT and asks them to rebuild the flow, despite the fact there is no documentation and no one else really knew exactly what it did. Both ManagerA and UserB then spend the next 6 months compaining that IT isn't very helpful.

[dgillespie · Accepted solution]

Thanks everyone for your replies.

Here is what we settled with: I created a Flow Admin account and assigned it a Business Premium license.  UserA creates the flow and adds me as an Owner.  I assign the Flow Admin permissions to that SP site/library.  Finally, I add the Flow Admin as an owner to the Flow and change the SP credentials on the Flow to the Flow Admins.

[anka]

Question- We have a Flow that sends outbound emails using the account of the user who created the flow. What would happen if the person leaves the organization, how will the outbound emails o when the mailbox is no longer active? I know that in the 'Send Email' action a "From" account can be specified for sending an email, but is it a good practice to do so or should we have a dedicated account(with an attached mailbox) for flows?

The information I am seeking- 

1. In terms of best practice, should we be creating a dedicated service account for flows? If yes, should the flows created by users be shared with this service account so they can be managed using one account?

2. What license should be assigned to the service account, E3 or E5?

3.  Should this account be assigned the global admin privileges?

Thank you.

[andeeh1974]

Has anyone from Microsoft replied to this thread?   Some clarity on what options we have in Flow would be helpful 

We have items that are created by UserA but then when the flow runs, it shows modified by FlowUser.  

Really what I would want is the flow to keep the original created by user as the modified by user.  

[DeeTronSEAM]

@andeeh1974,  I wholeheartedly agree that clarification from Microsoft on user accounts would be VERY helpful (either here or in the docs....though from the PowerApps learning-curve I've pretty much given up on my old-school mindset that official docs will ever again be up-to-date. Time and tech marches on!).

Yo, Microsoftians!
Specifically tricky is dealing with automation flows that use the O365 User connector/object and the Outlook.com connector.    All my years of using service accounts as Best Practice seem meaningless for Flow.  If, as another commented, that MS's perspective is that Flow is for "self-service" and we need to use Azure Logic Apps for enterprise-managed automation/workflows, it would be nice for them to be more explicit about that.  In my opinion their Flow demos sure fail to make that distinction.  If Flow is simply an MS-flavored answer to IFTTT, so be it (just say so).  But I'm still hoping it is the powerful enterprise-grade automation tool our organization needs (and which our IT team needs to be able to manage).

I hate to hear myself saying this, but SharePoint Designer (FOR Christ's sake!) was clearer and more capable (it seems) for handling user impersonation/user-context-switching.  I'm sure hoping that impression is wrong.  I know many things in PowerApps that were impossible a year ago now are possible...yet remain widely discussed online as if the old was still current.  It isn't that the official docs are not kept updated...it's just that they are too sparse in their details regarding real-world usage.  PowerApps and Flow would be impossible to learn, IMO, if not for these forums and other community-generated content (shout out to Shane Young!).

[DanyElHoyek]

What are you using as Names for the service accounts?

[Anonymous]

I have the same question - as it is an old post, is it the same solution today?  

If someone could point me in the direction to how i can identify which part of the flow is linked to a spesific useraccount i would appreciate it.

We have the case where a creator quit the company, the flow was moved to a new owner, but it does not run. And i am finding it hard to shift the ownership within the flow. 

[DeeTronSEAM]

Yes, @Anonymous , you need to go through the flow and look at each action that has a user-based connection (e.g. newer SQL Server connections, O365 actions such as Send Email, Word Online, OneDrive) and select a new connection which is using a current user (ideally a service account instead of an actual user's account).  This is done using the ellipses on the right side of the actions in Flow.  Here is a thread that provides some screenshots and better detail:  https://powerusers.microsoft.com/t5/General-Power-Automate/Need-to-use-another-User-s-connections-on-a-Flow/m-p/509441#M47881