Changing flow connection from a user account to a service account

[AnnetteM]

I have many flows that trigger from a submission to a Microsoft Form.  All of the flows I created were using my user account, however with the implementation of MFA, and best practice, I would like to change these to a service account. 

• Do I make the service account another owner to the flow?
• How do I change the existing connections from my user account to the service account?
• If the flow is triggered when a response is submitted to a form, does the service account need access to the form?
• If the flow needs to write to a SharePoint list, does the service account need to have permission to the SP list?

[yashkamdar · Accepted solution]

Hello Team,

Putting in a detailed answer for you that should clear out all your existing queries.

Question no 1 - Do I make the service account another owner to the flow

Yes, you need to do this because currently there is no option in Power Automate wherein you can just change original owner of the Power Automate.

I would request you to please upvote the idea below to cater the above requirement-

https://powerusers.microsoft.com/t5/Power-Automate-Ideas/allow-the-owner-to-change-the-ownership-of-...

Question no 2 - How do I change the existing connections from my user account to the service account?

Well there are 2 ways to do this-

1. Change individual connections of all the actions (which is too lengthy)

2. Take an export your Power Automate as a Package and then import the package with different user i.e Power Automate account.

How to export and import Flows is given below -

Export and import your flows across environments with packaging

I would highly recommend you to go ahead with option no 2.

Question no 3 - If the flow is triggered when a response is submitted to a form, does the service account need access to the form?

Yes, absolutely you will need access for the account the Power Automate is running under on the form whether this is a SharePoint form or a Microsoft form.

Question no 4 - If the flow needs to write to a SharePoint list, does the service account need to have permission to the SP list?

Again the answer is YES, if access is not there your Flow solution will not be able to write the file to the SP list and give you an UnAuthorized error.

If this reply has answered your question or solved your issue, please mark this question as answered. Answered questions helps users in the future who may have the same issue or question quickly find a resolution via search. If you liked my response, please consider giving it a thumbs up. THANKS!

[Nicolas07]

The workaround for this question 2 is such a nightmare...

You have to create a "fake" service account only for the purpose of PowerApps, make sure it has owner permissions to the related Forms and Sharepoint lists, share its credentials to other persons, export your flow, import it under the fake account and only them your Flow may run without hiccups even if you leave.

But in a large organisation there is no-way this can be done.

So now I end-up with a Group-owned Flow, running on a Group-owned Form and a Group-owned Sharepoint list, but if I lose my job tomorrow and my account is closed, then the Flow becomes immediately out-of-service because it has my personal connections and I cannot assign Group-owned connections...

[NigelP]

Hi

What about Service Principals for SharePoint connectors ?

Regards

Nigel

[AgainOpen]

Hi @yashkamdar thank you for your detailed reply.

I was wondering thought, when I got to export one of the fields is Environment and there is no reference on the article you sent on what that should be, do you know by any chance what do i need to write there or where can i find the name or what my environment is? thank you

[mioiox]

It might be a bit late for the OP but this might do the job for someone else, thus I am sharing it here.

Based on the original information by yashkamdar, these are the steps that can be followed in order to change the connection from one personal account to a service one. Tested and working at the time of writing.

There are two options to start with:

1. You want the flow to be created/owned/managed/configured and executed in the security context of a service account. This means that you need to know the password for the service account in order to make any changes to the flow, as you will need to logon to flow.microsoft.com using its credentials. You can always make another/your account an additional owner of the flow afterwards, of course.
2. You want the flow to be created/owned/managed/configured by you, but executed in the security context of a service account. This means that you will only need the credentials of the service account once, when you set up the data connection (see below). You can always make another account an additional owner of the flow.

In either case, these are the steps to follow:

1. If you already have some flows you want to be run in the context of the service account, login as your account and export them as ZIP files.
2. Depending on your selection of the options above you either log on to Flow using the service account (for opt. 1) or using your account (opt. 2).
3. Create a new data connection (flow.microsoft.com > Data > Connections > New connection > SharePoint > Connect directly > type in username and password of the services account.
4. If you chose opt. 1, when logged in as the service account, import the flows from the ZIP file.
5. If you chose opt. 2, when logged in as yourself, import the flows from the ZIP file.
6. No matter which option you chose, during the import process, for the connection select the new one you created (the service account one).
7. If you are using your own account for managing, during the import make sure you don't update the existing flow, rather create a new one.

At the end you will get a new flow that is using the new connection. And anytime you create a new flow, just make sure you select the correct connection (the service account one):

That should be it 🙂

N.B. Something useful about the service account:

• Can be an account without any license assigned
• Should have the necessary (read/modify) access to the SharePoint site/list/library and other resources. If there is no license assigned, granting permissions to the site itself might not be allowed. However, in the case of a Group-connected site (the modern Team site, that is), you can go to SharePoint admin center and make the service account an Additional admin. This will grant him permissions to the site and allow the flows to run.

Best regards and good luck!

[PCF_USer]

hi @mioiox 

Hi All,

I have created a flow to update the certain fields based on Onchange of a field.  I have changed the owner to 'service account' from me by adding the flow in existing solution as owner change is not supported for non-solution flow. 

Now, the problem is whenever I or anyone making changes to trigger the flow, it is working as expected but the update event is showing my name but it should (show)be updated by  the Service Account in Audit history as this is the current owner. We need to show the event is updated by service account beacuse other flow shd not run when chnages is made by service account which is not happening as the event is still showing my name

I do not how to change the connetion and connection references against the service account as it is a general account and to make connection we need to sign with that account.So, the connection reference is still using my id.I am not sure if this the reason and if it is then I am afraid of solution as i cannot login with service account to create the connection references

[mioiox]

Hi @PCF_USer,

When you say "I cannot login with service account", does this mean you don't have the service account's credentials (i.e., its password)? If you have them, did you try to follow my proposed solution above? And if yes, which option did you choose (as I am not sure I got it completely right from your description)?

[PCF_USer]

Hi @mioiox 

Yes I do not have service account to create flow and connection . 

I was told to change workflow in power automate and that workflow has owner as Service account but the problem is I have created the power automate from my account so I would be the owner.

Can you please help for above question

Also, though i have added it to solution to change the owner I need to create independed automate and distribute it.One way is to select the connection during import but for that also we need service account credential to create connection. Any idea? we can do it?

[mioiox]

I am not a Flow expert at all, but I am pretty sure that if you have the connection setup to use the service account, it doesn't really matter who the owner is - it will display in SharePoint that the changes were made by the service account.

Look on these screens. This flow is being created and owned by me, not by the automation.bot service account; this service account is only used for the connection, as explained above:

1. Flow connection configuration: 
2. List items being modified by this flow: 

You need to know your service account's password in order to configure the connection using its security context. Without its password you cannot achieve this and the flow will execute in your security context.

I hope I managed to clarify enough. Please take your time to read and understand my previous post.

Good luck!

[Anonymous]

We are also having these issues. It is preventing us from deploying between environments in DevOps for our phased releases between dev, sit, uat, pre-prod, and prod. All of which we would like to be on different release schedules for adequate Power App Lifecycle Management to be in place for our Apps.

When we deploy to the next environment from unmanaged to managed it breaks all the connections for flows that were created in our dev environment because they are using the developers user account when they are created. I have tried to explain this problem to our IT Department and get Support for this issue, as I am in Engineering, but they have not resolved it for us as of this date.

[melanietully]

I’m also looking for a way to deploy user created flows to other environments and ensuring that the connectors all use the service account.

would love if there was a send or copy to option so users send the flow to staging env then from there once approved click send to prod and svc account is added as the owner and connections all updated to service account. 
just can’t see how I can get a clear deployment process with all the intervention required … would welcome any ideas 🙂

[Anonymous]

I, too, had the same problem. Needing to switch the Approval and Outlook / 365 connections from my account to a Service Account. I stumbled upon a solution below.

Share the flow with an existing Service Account(SA).

Log in as SA. All steps after this is under SA account.

In PowerAutomate, you should see the flow in question under 'Shared with Me' tab. 

Perform a 'Save As' action on the flow you want changed. the flow, enter your new name as Flow name. Next dialog box will ask to create 'new' connections. Just click continue. The environment detected that the existing connections is not SA, so it wants to create connections with SA user.

Enter your new flow name. Then that's it. Test your flow.

Hope this helps / works.

[smharrod]

Make the account you want the flows to run as a Co-owner and log in using that account. If you have followed best practice and used connection references in all your flows, just create a new connection for the existing connection references, then click on each relevant flow in the Default solution and make sure the associated connections references are active with a green check. If they are not, you will need to create another new connection. You sometimes end up with a long list of multiple connections that don't work, so don't assume choosing an existing connection under that account will work.

If you are not using connection references, you will need to edit each flow and create and use a new connection for each action that needs one, which is not ideal, as you're making significant changes to a live flow, so will end up with an unmanaged layer if it is a managed solution. You can also try the Save As and create a new flow with new connections as suggested above, which is not ideal either as you'll lose all your existing flow run history.

Ideally this all needs thinking about as part of the deployment.