I too have made it a habit to use service accounts for flow. However, this does present a rather interesting bottleneck. Who gets access to the service accounts to create the flows?
What do you think of these options:

1. Create a Flow Group/Team/Site- The Service account will have full control of the site and or lists. Users can creat flows but then must share the flow so that the service account can take ownership. I wonder if there is a flow for this? Perhaps there could be a flow function to automatically give flow ownership to a list/library/powerapp if it detects the author account is changed

2. In an enterprise use something like secret server to gain access to credentials of the service account. this way you can create the flow using those credentials. 

Are any of these possible?

Our production flows are created and owned by service accounts. Connections within the flows are made with the service account as well. Then, the flow is shared to the group the administers the flows.

Thanks for the reply, Chris. I read this article on Flow ownership by list/library owners and tested it out on a Flow. If I understand correctly, this gives any list owner the ability to edit the Flow - which is great. Really. But it still doesn't solve the problem that the Flow itself is logged in to SharePoint using my credentials. If something happens to me and my credentials, what will happen to the Flow? Will it continue to run uninterrupted? Or will it stop until one of the other owners edits it to use their credentials? 

I totally agree that Flow is a much better tool than the SPD workflows in every way except this one. This gap is a grave risk to business continuity and one that is not adequately explained/disclosed to the users. 

Hi Chris McNulty ,

I share the concerns of Rachel_Davis  In regards to this. So, I have some questions.

I love flow and have done a lot (or around 20) and put them into production. On all of them I have added other owners since I want the flows to be accessible if I leave the company. My assumption is that the other owners will open the flows and edit them re-creating the parts of the flows that use my connections, thus securing that the flows can start running again if my account (and its connections) is removed or disabled. I have this marked as a manual process. I don’t like it, but I want to use Flow so I just accepted that we would need this manual part if I leave.

Would it be possible to change the ownership of the flows to a Group and automatically have the flow use another connection (a person from the group) if my account is gone?

Or same thing if I change the ownership to a list or library… will I get a new connection (one that is not mine) doing that?

Thanks in advance 😊

Best regards,

Malene

Thanks for sharing.  Yes, we think Flow is the right home for business process - more features and integrations than legacy SPD, which was deprecated five years ago.

Regarding Flow ownership, we introduced list/library ownership last year - you can assign a list or library as owner of a Flow (we do this automatically for system templates liek page approvals)  You can also add a group as owner.

Chris McNulty Again, I raise the same concern with Flow. Do we really think it's a good idea to tie business process automation to the credentials of an individual user rather than to the site or list? Yes, we can share a Flow, but even a shared Flow is still tied to the credentials of a SINGLE user.  Life happens. People change jobs, go on maternity leave, or get sick or even die suddenly. The potential for interruption to the business is massive, especially when we're talking about onboarding or travel approval. 

You market Flow towards end users but it creates a massive risk for interruption to the business. When you add in the fact that many departments run everything through their local power user, we've magnified that risk exponentially. Now it's not just one or two Flows that will go down, it's the entire department.

What are the plans/recommendations from Microsoft to address this risk? This is the one thing that is keeping us tied to SharePoint Designer workflows. They won't die if the user does.