Forum Discussion
Flow Credentials: Best Practices?
I am just getting started with Flow and I want to try to do things with best practices in mind from the beginning. I would like to create a flow on a Sharepoint list which of course requires credenti...
We use several flow accounts for everything. It's somewhat easier to manage but also takes the guess work out of who an email is going to come from or who has access to what. It's also handy for troubleshooting because we know if those accounts pop up, it's specifically flow.
Your flow account doesn't need to be global admin - it just needs access to whatever you are using it for. So if it is updating a list item, it needs that permission to the list/site. That said, often the flow account ends up with fairly beefed up perms. That's also another reason to think about centralizing the accounts you're using. I realize the context of the flow will run as whoever you add the connector as, but again, there's something to be said about knowing exactly which account to look for. I realize people will argue that a service account flow isn't as good for security but that really depends on how you implement it. I'd argue the other way, you know exactly which account does what and you be as granular as you need, knowing that account should always have access to specific areas and anything else is an anomaly to look at.
Don't worry specifically about E3 vs. E5. In fact, go cheap there and out the extra money into Flow plan 1 or 2 (premium plans). You will find that the premium plans give you not only more flows but a few additional kinds of flows.
We have at the moment the same discussion, run as concept and sending e-mails.
Our view at the moment do not offer business critical applications using Flow.
Means do not allow set a Flow licenses to a dummy account so you can restrict.
Use dummy accounts only if the IT department is the owner of the Flow based solution.
I you give an normal user the permissions to use a dummy account, he can use the account where ever desired, he can share the password to user nothing to do with Flow and so on.
The end user using a dummy account is responsible for the solution and if the solution is business critical like finance dependency or issues producing delay in daily work for mass people.
The IT department will not be able to support end user customized Flows and not able to solve business critical solutions if the team is not included in the solution design.
We also thinking about something like "Terms and Condition" on top so everyone is aware about risks and what is supported and may be conditions when you can have a service account .
We talking here for example about 100k user be able to use Flow and again and again the same questions "run as" , send e-mails.
It means offering the usage of dummy accounts with strong policy, aware about the risks like owner off, how to use from company security policies view.
Team flow is a good idea for IT teams but think about "normal user. A finance team is interested on a running solution and not interested to manage daily issues coming from Flow.