Using Service Principal in Power Automate/Flow

[nagaraja2026]

Any CDS trigger or action requires a connection to CDS environment.

While adding connection, we can choose to sign in with individual user account or Service Principal.

If we choose to sign in with individual user , CDS action runs in that user context and in auditing it shows as the user performed that action.

It may cause problems in some scenarios like audit checks/troubleshooting.

So better way to do it is sign in with service principal / application user. By creating service principal, we are indirectly creating an identification for the flow.

A service principal is created by registering an Azure AD application and then creating a corresponding application user in CDS.

When you use an application user/service principal on the CDS connector all actions are performed by that user on behalf of organization users who are triggering the flow by performing some action (Which is called impersonation ).

Application users get the permissions from the security roles associated with the CDS app user. 

Below steps are required to create Service Principal / Application user.

Step 1: Register your application in Azure Active Directory.

Refer this article from Microsoft docs to create application in Azure AD. And note down client id/application id, client secret , tenant id .

Step 2 : Create application user in CDS environment and assign security role(custom).

Refer this article from Microsoft docs to create application user and assign security role.

Step 3: Add new connection and sign in with service principal in flow.

Enter client id/application id, client secret, tenant/directory id that we got from Step 1 and click on create.

That’s it .

Hope it helps.

Original post from my blog : https://powerofpowerplatform.com/using-service-principal-in-power-automate-flow/

[JeremyTBradshaw]

Hi @nagaraja2026 

Do you have any idea if this same capability to use a Service Principal is likely to come to Power Automate for other things like SharePoint?

I find the need to use user credentials so much in Flow to be less favorable than the App-only approach.  Having to refresh connections when passwords change or making service user accounts feels counter-intuitive for automation.

[bran]

What happens when the secret expires? Will all the flows stop working? 

[NielsL]

@branthat just happened for me - all flows stopped working due to an expired client secret.

And there is no way you can update the the client secret for an existing service principal in Power Automate. You need to create a new one. And as far as I can see - there is also no easy way to replace all connections with the new service principal. 

Using the 'Switch account' functionality under connections will expect a normal user with a username and password. 

[NigelP]

Hi

This is for DataView aka CDS steps.

What about using Service Principals with other PowerAutomate Flow Steps ?

Is there a list of PowerAutomate Flow steps which are Service Principal aware ?

Regards

Nigel

[Aedu]

Hi

What about packaging and transferring connection references between environments? In my experience it is a mess!

We created a flow in our development environment with a service principal and the required connection reference. Packaging the flow and the connection reference into a solution and exporting the solution is easy. But while importing the solution into the target environment the problems start. During import the connection reference is listed as expected. As this is the first time import the connection reference is empty. Problem is, you can click on "create new" for a new connection but are then unable to create the Connection with a service principal. Even worse you have to edit the flow and create a new connection reference with the desired service principal. And that in a managed environment!

Is it as it is or do we something completely wrong?

Regards

Adrian

[AadityaAggarwal]

Hi

I have a service principal connected to my environment and i have even added it as a co-owner in the flow. But instead of any CDS actions, i intend to send an email outlook and post ms teams card. I am unable to sign in via service principal.

Currently, all my email and teams actions are configured to my email id and the result is that i am the sender address all the time. How can i set a service principal or custom name as the sender by setting connection reference. Or do i need a service account to achieve this? 

regards

Aaditya

[nattomatto]

@AadityaAggarwal you aren't going to be able to use the service principal in the native connectors for outlook or Teams.  To use those you are going to need a licensed account (a service account that you mentioned would suffice) with access to the Teams and email box that you are using.

To use the service principal, you would need to grant the principal the appropriate rights within your Azure App, and then use the Graph API with a custom connector or HTTP action to do what you want to do.  

[rg0173]

Has anyone figured out how to connect either a Service Principal or Service Account to the Content Conversion and OneDrive for Business action? 

@nagaraja2026

[MattMMeyer]

OneDrive for business, SharePoint, etc do not have direct Service Principal uses with the native connectors.  You will need to use the Graph API and use your Service Principal as the "app" authenticator.

Check out my video:
https://youtu.be/6v3pP4Z-iL4?si=F1G3R1IBklW_ktgM

That goes over how to do it within SharePoint.  OneDrive is similar.