Showing results for 
Search instead for 
Did you mean: 

Using Service Principal in Power Automate/Flow

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 :



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.

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

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




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 ?








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?






About the Author
  • Experienced Consultant with a demonstrated history of working in the information technology and services industry. Skilled in Office 365, Azure, SharePoint Online, PowerShell, Nintex, K2, SharePoint Designer workflow automation, PowerApps, Microsoft Flow, PowerShell, Active Directory, Operating Systems, Networking, and JavaScript. Strong consulting professional with a Bachelor of Engineering (B.E.) focused in Information Technology from Mumbai University.
  • I am a Microsoft Business Applications MVP and a Senior Manager at EY. I am a technology enthusiast and problem solver. I work/speak/blog/Vlog on Microsoft technology, including Office 365, Power Apps, Power Automate, SharePoint, and Teams Etc. I am helping global clients on Power Platform adoption and empowering them with Power Platform possibilities, capabilities, and easiness. I am a leader of the Houston Power Platform User Group and Power Automate community superuser. I love traveling , exploring new places, and meeting people from different cultures.
  • Read more about me and my achievements at: MCT | SharePoint, Microsoft 365 and Power Platform Consultant | Contributor on SharePoint StackExchange, MSFT Techcommunity
  • Encodian Owner / Founder - Ex Microsoft Consulting Services - Architect / Developer - 20 years in SharePoint - PowerPlatform Fan
  • Founder of SKILLFUL SARDINE, a company focused on productivity and the Power Platform. You can find me on LinkedIn: and twitter I also write at, so if you want some Power Automate, SharePoint or Power Apps content I'm your guy 🙂
  • I am the Owner/Principal Architect at Don't Pa..Panic Consulting. I've been working in the information technology industry for over 30 years, and have played key roles in several enterprise SharePoint architectural design review, Intranet deployment, application development, and migration projects. I've been a Microsoft Most Valuable Professional (MVP) 15 consecutive years and am also a Microsoft Certified SharePoint Masters (MCSM) since 2013.
  • Big fan of Power Platform technologies and implemented many solutions.
  • Passionate #Programmer #SharePoint #SPFx #M365 #Power Platform| Microsoft MVP | SharePoint StackOverflow, Github, PnP contributor
  • Web site – Youtube channel -