Forum Discussion
Flow Credentials: Best Practices?
MicrosoftHi Courtney!
Its totally ok to use your own credentials, as you can then share your Flow out with teammates so its not only owned by you, in case something were to happen or you were to leave.
Also, when a password chages, Microsoft Flow is able to still persist. The only way that Flow connections will expire is if your environment admin were to kill your tokens. Not refresh them.. Kill them.
If you want to get quick help on Flow related items, i would reccommend you join the official community at: https://powerusers.microsoft.com/t5/Microsoft-Flow-Community/ct-p/FlowCommunity
Let me know if i can be of any more help!
- Jon
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.
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.
I know this is an old post, but looking to finally create some production flows, and my test flows I've had have actually had "You need to fix your connections" pop up consistently on my account even thou I've never reset tokens. Unless resetting my password manually in AD causes that to happen :P.
Anyway, seems service account is the safe bet just for future proofing if someone leaves the org.How Flow uses accounts is way more confusing than it should be. There is a lot of room for improvement and clarification in the documentation about exactly what account is going to be used, what perms are needed and how it going to show up. Sending emails is one area that needs a lot of attention.
Wow, so what I'm reading in this thread is that the flow doesn't actually rely on credentials at all but is solely dependent on the the token. That's actually quite convenient and extremely powerful. So truly, a service account isn't needed but I'm guessing it's not the worst idea, at least for organizing all your flows. How long are those valid? I suppose I could actually look it up.................
I don't understand how it can be okay to use individual user accounts for production flows. Flows typically require connectors. For example, a flow may send an email via Outlook. If the Outlook connector is defined using a personal account, when the person leaves and their account is disabled or deleted, the connector will no longer function, breaking the flow. Right? It wouldn't matter that the flow was a team (shared) one; the connector would still have to be rebuilt using a different (active) account.
If, in contrast, a managed service account is used, the flow will continue to work as long as the account remains active.
