Answered

Flow Ownership and SharePoint - Best practices

(1) Share

Report

Posted on by 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:

UserA makes a flow which requires certain permissions on SP doc libraries and lists
UserA leaves company
Ownership of flow changes to new hire UserB
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!

Categories:

General topics

I have the same question (0)

All responses (14)

Answers (1)

v-monli-msft Microsoft Employee on at

Like (2)

Report
Copy link

Link copied!

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

Was this reply helpful? Yes No
sergeluca 500 on at

Like (2)

Report
Copy link

Link copied!

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

Was this reply helpful? Yes No
Mike2500 1,247 Super User 2024 Season 1 on at

Like (2)

Report
Copy link

Link copied!

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.

Was this reply helpful? Yes No
dgillespie 84 on at

Like (0)

Report
Copy link

Link copied!
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?
Flow Service account, UserA, UserB are all in same SP group
FlowA is created by UserA and also owned by Flow Service Account and UserB
UserA leaves and his/her account is deleted
FlowA still works?

Was this reply helpful? Yes No
Mike2500 1,247 Super User 2024 Season 1 on at

Like (3)

Report
Copy link

Link copied!

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)

Was this reply helpful? Yes No
dgillespie 84 on at

Like (0)

Report
Copy link

Link copied!

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.?

Was this reply helpful? Yes No
Mike2500 1,247 Super User 2024 Season 1 on at

Like (7)

Report
Copy link

Link copied!

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.

Was this reply helpful? Yes No
Verified answer

dgillespie 84 on at

Like (9)

Report
Copy link

Link copied!

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.

Was this reply helpful? Yes No
anka 66 on at

Like (0)

Report
Copy link

Link copied!

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.

Was this reply helpful? Yes No
andeeh1974 19 on at

Like (1)

Report
Copy link

Link copied!

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.

Was this reply helpful? Yes No