How to handle leavers in Power Automate

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.

Share
Pieter Veenstra

Business Applications and Office Apps & Services Microsoft MVP working as a Microsoft Productivity Principal Consultant at HybrIT Services. You can contact me using contact@veenstra.me.uk.

View Comments

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

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

Recent Posts

Calculate the Sum for a SharePoint column in Power Automate

Last week Shane Young asked me about calculating the Sum for a SharePoint column in…

2 days ago

Object must implement IConvertible in Power Apps

In Power Apps when you do a Patch to create a new item or to…

6 days ago

Get started with adaptive cards in Power Automate

Getting started with adaptive cards can be difficult. In this post i have written some…

2 weeks ago

Create PDF documents from data in Power Automate

In this post I will look at how to create PDF documents from data. Use…

2 weeks ago

Unnest nested arrays in Power Automate

We all know this problem, you have a nested array in Power Automate but how…

3 weeks ago

Advanced settings not loading in Power Platform

Yesterday one of my clients showed me an issues where the Advanced settings didn't load.…

4 weeks ago
%%footer%%