Nobody likes it when people leave your organisation, but apart from the emotional part of this. What do you do when leavers own flows in Power Automate?
Flow Owners
Last week I was asked about what to do when owners of flows leave. In this post some guidance on how to handle leavers.
In this post I will use a user account Lucy Eaver who creates some flows. in this case I’m only going to look at automated cloud flows, Instant cloud flows and Scheduled cloud flows
Did you notice that the names of these type of flows has changed today? We now have cloud flows vs the Desktop flow and Business process flows.
An Automated flow
Lucy has created an automated flow as shown below.
An instant flow
Then Lucy creates another flow, this time a manually started flow.
A Scheduled flow
Running the flows
Now as a create an item in the Testlist in SharePoint and I start the manual flow i’m getting some emails.
We can now see that the Manual flow sends out emails as myself and the schedule and automated flow still run as the owner of the flow.
Now Lucy turns into Mrs L.Eaver, and her account is going to be disabled. What will happen to the flows?
Disabled user account
The manual flow still works, but the automated flow is now showing some issues with the trigger:
And also the scheduled flow is now happy:
Ok, this is all expected and Mrs L.Eaver’s email address is not available anymore for use anymore.
But what do we do? The manual flow was shared with another user account and the first time a user runs this flow they give consent on the flows to use their account for the connections in the flow.
But the Scheduled and Automated flows were not ok as these flows are running as the flow owner.
What should we do if these flows are critical to our business?
First of all you shouldn’t have flows owned by just one person.
Also tools like the Centre of Excellence can help identifying which flows and apps someone owns.
Power Platform Admin Center
In the Power Platform Admin Center you can find all your flows back and also everybody else’s. This includes our leaver’s flows.
In the below awful interface ( there is a load more button at the bottom of the page that you need to use to load all the flows) you can sort by owners or modified time to find all Lucy’s flows.
And from here we can take ownership of the flows by sharing the flows with the right users.
So now that we have identified the problem flows we can share the flows with other people. But this could of course happen again and again.
The answer is service accounts. Share flows with a service account that is managed centrally.
Multiple environment
As your efforts in the Power Platform mature, you will find the need for multiple environments, typically you would end up with Development, Test and Production environments. Personally I would create apps and flows using serviced accounts in test and production environments, while in development I could still use my personal account.
Pieter, thanks again for your enormous wealth of tips and advice. Your last line was the key “The answer is service accounts” which we have adopted. Let me add another piece of advice which has worked for us and I think is important. Connections.
Even if you share a flow, the connections in many types of flows will be made with the user who “created the step” in the flow that used that connection.
You do not want to have a developer who “leaves” and you then have to modify all of her flows for the connections.
We have a service account accessible by developers, which has admin rights to most of our resources.
I have two different solutions:
1) export flow and import as service account, which will create all new connections
2) or, easier solution, a) share the flow with the service account, b) remove all the connections from the flow c) reopen the flow and remake all the connections.
I believe that any flows which are shared to the entire organization should be owned by a service account (as you mentioned).
I have an even easier solution, assuming the service account already has the necessary connections created. After sharing the flow with the service account, log in as the service account and create a copy of the flow. It will automatically use the service account’s connections. Then, turn off and delete the old flow and turn on the new one. Of course, to prevent all this, we now create all our flows with the service account. I am speaking of our IT unit, of course. Users elsewhere in the company would not do that, although we don’t yet have too many flows created outside of IT.
Personally I create flows in test and production environments only with a service account.
That is what we have started doing as well.
[…] Nobody likes it when people leave your organisation, but apart from the emotional part of this. What do you do when leavers own flows in Power Automate? Flow Owners Last … read the how-to-handle-leavers-in-power-automate post […]
Careful! There be dragons!
“A” Service Account vs. “MULTIPLE” Service Accounts should be considered. It could be considered a poor security practice to have a SINGLE Service Account with permissions on all the resources needed for Connections within your Flows. (AKA: God-mode).
Perhaps a better model for your org is to create a service account for EACH TEAM (or for each large project, etc) that creates PowerApps and Flows within your org.
That way there is a smaller scope drawn around what the service account has access to in the event it is compromised.
Also, service accounts need to be assigned an O365 license if you want to build Flows/PowerApps using them.
– This can cause some friction if your org uses MFA.
– You may also face throttling issues if a single service account is executing multiple Flows.
Lots to consider.
I would say that the practice of “sharing” Flows with ANY HUMAN IS A BAD PRACTICE.
You have to really trust that person! They could technically re-use your connection to send emails/access data/etc.
A safer, alternative way to handle “Leavers” is:
1. Always put error handling around Actions that rely on a specific person’s connection. Have the error path email the support teams shared inbox/Teams channel
– Now you know as soon as it fails due to connection
2. When moving Flows from DEV to PROD environments, save the exported Flows to a centralized location.
3. BEFORE someone leaves (if possible) have the new responsible person import the Flow. It will then require them to create Connections in their name.
– No more “reuse” of Connections
“Connection Reuse” is one of the biggest security flaws in Power Automate. The tool should really check the person logged into Flow vs. the person authenticated to the Connection before allowing execution.
Anyway! Fun topic!
Totally agree that multiple service accounts is better. Creating one service account for all connections is indeed not the best option.
Hello. Thanks for your blog. Very helpful.
For security reason, we try to have a service account dedicated to each “type of connection” by application (= project).
So basically, if we have a Power Automate which uses 3 connectors (Dataverse, Sharepoint, Outlook), I will use 3 service account which have limited access following the scope of the Power automate.
– The connection used by Dataverse has a security role scoped against the app
– The connection used by Sharepoint has only access to the site which is used by the app
– …
In the same idea, we want to have a service account for the ownership of the Flow (to avoid the problem that you explain in this article). I guess that this service account must have a license “Customer Engagement” or something similar (maybe a licence “per user” is enough), isn’t ?
Thanks for your help
Hi Julien, When you have a user with a premium licence for Power Automate then that user account can access Dataverse and other premium features. Licensing can be complicated. I’m happy to have a chat about this. Please feel free to open a chat on this site.
Hi Pieter,
What should be the best practice for service accounts that are running the flows and are flow owners? especially in terms of ‘password expiry’ and ‘MFA’ requirement for this account?
Can we have these two things enabled on the service account? if yes, what needs/will happen when the password expires and/or there is a prompt for mfa?
Thanks
SP
This is a good post that will give you a quite good workaround for this problem:
https://blog.peterdahl.net/2018/01/09/microsoft-flow-and-azure-conditional-access-azure-mfa/
Hi Pieter,
Hoping u r still monitoring comments as above states that as an Power Platform Admin, in my case licensed with P2 & Free, I should be able to see all Flows. Unfortunatley this is not the case. It is a service account with Environment Maker and System Administrator Roles and yet I can only see a small subset of Flows. Luckily we have the “Microsoft Center of Excellence ( Starter Kit)” installed so i can see and share Flows missing in Admin center but wondered if you have any insight into why the Admin Centre does not list all Flows.
Hi Mike,
Sorry for the delay inn replying. Your comment ended up in spam.
Do you know which flows you can and can’t see? is there any pattern? Can you only see the flows that you either own or that have been shared with you?