Move a Flow Connection to a Service Account: Practical Workflow for Business Users

When the person who created a Power Automate flow leaves the company or changes roles, the flow stops working because its connections are tied to that user’s account. A service account is a dedicated user account that is not tied to any one employee, so flows linked to it keep running even when staff changes occur. This article explains how to move an existing flow connection to a service account using a step-by-step workflow that any business user can follow. You will learn how to identify the current owner, create or locate a service account, update connection references, and test the flow to confirm it runs without interruption.

Why Flow Connections Break When Users Leave

Power Automate flows use connections that are tied to the identity of the person who created or last edited the connection. When that person’s account is disabled or deleted, the flow cannot authenticate to services like SharePoint, Outlook, or Teams. The flow enters a suspended state and shows an error such as “Connection not found” or “Access denied.” Moving the flow connection to a service account prevents this problem because the service account remains active regardless of employee turnover. A service account is a non-human user account that has its own license and permissions. It is not used for daily logins and is managed by IT. Before you move the connection, you need to know the current flow owner, have access to the service account credentials, and have edit permissions on the flow.

What You Need Before Starting

You need the following items to complete this workflow:

• Flow edit permissions: You must be an owner or co-owner of the flow. If you are not, ask the current owner to share the flow with you.
• Service account credentials: You need the username and password of the service account. If no service account exists, you must create one in Azure Active Directory.
• Appropriate license: The service account must have a Power Automate per user plan or a Microsoft 365 license that includes Power Automate capabilities, such as Office 365 E3 or E5.
• Service account permissions: The service account must have the same permissions as the original user for each service the flow accesses. For example, if the flow sends email from a shared mailbox, the service account must have delegate access to that mailbox.

Steps to Move a Flow Connection to a Service Account

Follow these steps to move the connection from the current user to a service account. The process works for both classic cloud flows and new solution-aware flows.

1. Identify the current flow owner and connections
   Go to Power Automate at make.powerautomate.com and sign in. Select My flows from the left navigation. Find the flow you want to migrate and click the flow name to open its details page. On the details page, look under the Owner field to see the current owner. Scroll down to the Connections section to see which services the flow uses. Write down each connection name, such as SharePoint, Outlook, or Teams. You will need this list to create new connections for the service account.
2. Create or locate the service account
   Go to the Azure Active Directory admin center at aad.portal.azure.com. Select Users and then New user. Fill in the User Principal Name (for example, flow-svc@yourdomain.com) and display name. Assign a strong password and uncheck “Require password change at next sign-in.” Under Licenses, assign a license that includes Power Automate. If a service account already exists, skip creation and verify that it has a license and is active. Write down the service account username and password.
3. Add the service account as a co-owner of the flow
   Return to the flow details page in Power Automate. Click Edit in the top menu. In the flow designer, click the three dots (more options) next to the flow name and select Share. In the sharing panel, enter the service account username and select Add as co-owner. This step gives the service account edit permissions on the flow. Click Close. Now the service account can modify the flow and create new connections.
4. Create new connections for the service account
   Sign out of your current Power Automate session. Sign in to Power Automate using the service account credentials. Go to Data > Connections in the left navigation. Click New connection and search for each service you identified in step 1, such as SharePoint or Outlook. For each service, select it and click Create. Follow the sign-in prompts to authenticate the service account. After creating all connections, sign out of the service account and sign back in with your normal user account.
5. Update the flow to use the new connections
   Open the flow again from My flows. Click Edit to enter the designer. For each action or trigger that uses a connection, click the action to select it. In the action pane, look for the connection field. Click the current connection and select the new service account connection from the dropdown list. Repeat this for every action in the flow. When you finish, click Save in the top menu.
6. Test the flow and remove the original owner
   Click Test in the top menu and select Manually or Automatically depending on your flow trigger. Run the flow and verify that it completes successfully without errors. If the flow uses a trigger that waits for an event, send a test email or create a test item in SharePoint to trigger it. After confirming the flow works, go back to Share in the flow details and remove the original owner. This step prevents the flow from being linked to the old user account. Click Remove next to the original owner’s name and confirm.

If the Flow Still Has Issues After the Move

Even after following the steps above, you might encounter problems. Here are the most common issues and how to fix them.

Flow Shows “Connection not found” Error

This error means one or more actions still reference the old connection. Return to the flow designer and check every action. Expand each action’s settings and confirm the connection field shows the service account connection name. If you missed an action, select the correct connection and save again.

Service Account Cannot Access SharePoint or Other Services

The service account lacks the necessary permissions on the target resources. For SharePoint, give the service account at least Read access to the site collection. For Outlook, ensure the service account has delegate access to any shared mailboxes the flow uses. For Teams, add the service account as a member of the relevant team or channel. Contact your IT team to grant these permissions if you do not have the authority.

Flow Fails After Original Owner Is Removed

If you removed the original owner before testing, the flow may still have connection references that only the original owner could authenticate. Re-add the original owner temporarily, then follow step 5 again to update every connection. Test the flow while the original owner is still a co-owner, then remove them after a successful test.

Original User Connection vs Service Account Connection: Key Differences

Item	Original User Connection	Service Account Connection
Owner	Individual employee	Dedicated non-human account
License requirement	User’s own Power Automate or Microsoft 365 license	Service account must have a compatible license
Impact of user leaving	Flow breaks when account is disabled	Flow continues running
Permission management	Permissions tied to the user’s identity	Permissions must be explicitly granted to the service account
Password expiration	User password changes affect flow	Service account password should be set to never expire

Moving a flow connection to a service account prevents downtime when employees leave. After completing the steps, the flow runs under a stable identity that is not affected by personnel changes. As a next step, consider setting the service account password to never expire and enabling multi-factor authentication with an app password for security. For flows that use premium connectors, verify that the service account has the appropriate Power Automate per user plan with attended RPA or unattended RPA capabilities if needed.