Flow Credentials: Best Practices?

[Courtney Prothero]

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 credentials. I don't really want to use my own credentials since I can't guarantee that I'll always be the one at this desk. Do others use service/dummy accounts created for this purpose?

Also what happens to a flow when a password changes? Does the person with that password have to go in and reauthenticate the flow?

TIA

[#2]

Good question. Did you ever get it answer?

[#3]

I'd love to know this too.  I have a couple flows setup where previously we would have used a sharepoint designer workflow or even a service account.  So far....................... they haven't choked because they've needed reathentication, but I've been waiting for that to possibly pop up.

[#4]

Have you seen the new Team Flows? I think that this could be a good approach for many of these scenarios. https://flow.microsoft.com/en-us/blog/team-flows/

[#5]

I didn't get an answer but we discussed it internally and decided the best option for us was to make a service account with a non-expiring password. I haven't had a chance to test this extensively yet but I'm also going to check out the team flows mentioned in this thread.

[#6]

I think that's the best bet, just to be on the safe side...... for now.  In a production environment, you don't want to be messing with accounts, etc.  That said, I'm very impressed with Flow and how it's worked so far.  With a little elbow grease and some time to figure it out, it's really useful and works well (and it's fast).  There's a lot of flexibility built in that's not obvious right away.  

That said, I'd love to see more documentation and examples.  I know I can do quite a lot but I don't know HOW without extensive searching around sometimes.  That's life with new services though, especially something as robust as Flow.

[#7]

Hi 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

[#8]

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.

[#9]

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

[#10]

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.

[#11]

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.

[#12]

@Jon Levesque 

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.

[#13]

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.

[#14]

 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.