A Visual Guide To Power Platform Service Principal Setup

A Visual Guide To Power Platform Service Principal Setup

Using a Power Platform service principal account is an awesome way to securely run your Power Automate flows. Service principals have system the administrator role and stay logged permanently stay logged in with a special type of permanent password called a client secret. No user can log into the service principal account which makes connecting them with Power Automate much safer than a shared admin account with a user name or password. In this article I will show you how to setup a Power Platform Service Principal account and use it with Power Automate.


Table Of Contents:
• What Is A Service Principal?Register An Application In AzureConfigure API Permissions For The ApplicationCreate A Secret For The Power Platform Service PrincipalSetup An Application User For A Power Platform EnvironmentRun A Power Automate Flow Action As The Service Principal





What Is A Service Principal?

A Dataverse flow action can be run by a user account or a service principal. For example, let’s say we created a flow for a table called Fundraisers and wanted to set the field fundraiser goal to 1,000,000 when the flow is triggered for a record. We do not want a user account to run the action because the record would show that the user modified it when in fact it was done automatically by the flow. So instead, we can use the service principal by selecting as the connection.

The service principal is non-interactive user account for Dataverse (or other applications) with elevated permissions. It connects Flow directly with Dataverse to perform tasks. A service principal account is not a “named user account.” No user can login to it with a username and password (meaning better security). This means it does not need to be re-assigned when a user leaves the company.




Register An Application In Azure

The first step in creating a Power Platform service principal is registering an app in Azure Active Directory. Go to portal.azure.com and open the app registrations service.



Select new registration.

Name the application Power Platform Service Principal and allow Accounts in this organizational directory only to use it. Then click Register.



After clicking Register we are taken to the overview screen where all essential details of the app registration can be found.




Configure API Permissions For The Application

Now that we have registered an application the next step is to setup the app permissions. Choose API permissions from the left-menu then select Add a permission.



Choose Dynamics CRM from the Request API permissions menu that appears.



On the Dynamics CRM menu choose the Delegated permissions type and check the box beside user_impersonation. Then click Add Permissions.



We must also grant admin consent for our app to use the Dynamics CRM API across the entire tenant. A normal user would be prompted grant consent the first time they use an app. But since the Service Principal account is not controlled by any individual user we must do it from the API Permissions screen in advance.



Choose yes when the Grant admin consent confirmation appears.



We are now done setting up Dynamics CRM permissions for our app.





Create A Secret For The Power Platform Service Principal

The final step in setting up our application is to protect it from unauthorized users by giving it a password. In Azure the application password is called a secret. Go to the certificates & secrets page and select New client secret.



Give the secret a description and choose the maximum expiration date (24 months) then click Add.



When the secret is created it generates Secret ID (a unique identifier) and a Value (the password). It is important to copy the value because once we leave this screen we won’t be able to see it again. If we ever lose the key we will need to delete the secret and create a new one.



For the purposes of this tutorial, copy and paste the secret value into notepad so we can use it in later on. In the real world we would want to store the secret in Azure Key Vault. Key vault is a secure place to store passwords, secrets & certificates in one centralized place.





Setup An Application User For A Power Platform Environment

An application user is a special type of non-interactive user that can perform tasks for us in Dataverse. We can link it to our application in Azure and give it system administrator privileges so it can be used as a service principal. To do this, go the the Power Automate maker portal and open Admin Center.



Open the environment we want to create the application user in.



Select Settings.



Expand Users + permissions and select Application users.



Create a new app user.



Add the Power Platform Service Principal app we setup in Azure. Assign a business unit then select the system administrator security role. Then click Create.



One further step is required here. Open the details of the Power Platform Service Principal account and click refresh to sync the app name from Azure Active Directory. Once this is finished we can close the admin center.





Run A Power Automate Flow Action As The Service Principal

To run a flow action as a the Service Principal with system administrator permissions open a Power Automate flow with any Dataverse action, select the three dots and choose + Add new connection.



Connect with a service principal.


Fill-in the Service principal details with the following information and click Create when completed:





Now we can select the Power Platform Service Principal to run the flow action instead of a user account.





Questions?

If you have any questions about A Visual Guide To Power Platform Service Principal Setup please leave a message in the comments section below. You can post using your email address and are not required to create an account to join the discussion.

Matthew Devaney

Subscribe
Notify of
guest

54 Comments
Oldest
Newest
Inline Feedbacks
View all comments
EZ Otb
EZ Otb
2 years ago

Hi Matt, I think that this is exactly what I was looking for, but the following sentence is unclear: “Since a service principal is not a user account, no user can login to it with a username and password (meaning better security) and it will need to be re-assigned when a user leaves the company.”
Should this read “and it will not need to be re-assigned when a user leaves the company?

EZ Otb
EZ Otb
2 years ago

Hi Matt, Second question: Can this be set up for an environment that uses only Power Apps, Power Automate and SharePoint? Presently we do not use Azure or other platforms. Thank you

Kathryn Birstein
2 years ago

It really only works with Dataverse since Dataverse has an “Application” user type, right? SharePoint “Send an HTTP request to SharePoint” action will use the credentials of the owner of the flow although you could probably use the straight HTTP action with this as Matthew suggests. However, SharePoint does not have an “Application” user so I don’t know how you could authenticate with SharePoint with a client secret. If anybody has a different opinion let me know!

Rohit D
Rohit D
2 years ago

HI Matt, Great article. Thank you for taking time to write detailed explanation. I have a question from licensing perspective. If we replace article example from CRM to sharepoint (or any product that needs license), how is service principal allowed to make CRUD operation? Or this is purely based on License of Power automate writer/owner?

Native Nass
Native Nass
2 years ago

Hi Matthew

How is licensing addressed concerning this service principal when using premium connectors ?

Kind regards

Melanie tully
Melanie tully
2 years ago
Reply to  Native Nass

I’d be interested in the licencing too we have E5 (gov tenant)

Micael Levesque
Micael Levesque
1 year ago

Hi, the service principal does not require any licensing as Microsoft allow one application user per powerPlatform environment. This is for all the Dataverse Premium actions. Others actions from PowerAutomate cannot use this service principal and it does not concern.

Also, the principles brought by Microsoft is that all the actions have to stay within the application functions. If you try lets say to pull data out and send them with rest call to something else, you are out of context and you need proper premium licencing then.

Last point, this guide will not quite complete your user application as a service principal. An exemple is that this app will not be allowed to call power platform API from scripts. This step needs to be done too :

https://learn.microsoft.com/en-us/power-platform/admin/powershell-create-service-principal

Last edited 1 year ago by Micael Levesque
Mark Slosberg
2 years ago

2 Quick questions.

1) Can you use a Service Principal to connect to a SQL Server database in the same way you are connecting to a Dataverse environment? I am not very happy with the way the IT organization is doing it now with an Admin account?

and

2) will it have the same 16 Flow per connector limit?

Ben H
Ben H
2 years ago

I think this is coming to more connectors in the near future, fingers crossed for SharePoint!

Nate Auchter
Nate Auchter
1 year ago

Hey Matt, great article. Do you have any understanding of limitations to this approach? If the application has been given consent to a third party tenant, and app user set up in that dataverse as well, would this approach to the Power Automate connection work across tenants? Or is that not something that Microsoft supports? Currently I get a “Forbidden” error when attempting to connect to an external dataverse.

Jatin B
Jatin B
1 year ago

Is service principal supported for SharePoint Online and Outlook 365 triggers/ actions?

CRM Consultant
CRM Consultant
1 year ago

If I created “Service principle connection reference” , Only I can see it and use it. How it can be made available for all users?

Matt Ruma
1 year ago

Hi Matt,

Thanks for the article!

This article https://www.m365princess.com/blogs/2022-07-25-why-your-service-principal-doesnt-need-a-dynamics-user_impersonation-scope says you don’t have to add permissions, but rather you add the service principal to the environment.

This worked for me.

Wondering what the best way is to accomplish this?

Niels
Niels
1 year ago

Hi Matthew,

Do you know if it is possible to update the client secret of a service principal when it expires?

Or is the only alternative to create a new connection reference – which the needs to be updated in all flows?

Oscar
Oscar
1 year ago

Hello Matthew,

I created a Microsoft Dataverse connection with a service principal. Now that I want to change the secret, I don’t see the option to update it.

When I click the “Switch account” option, a window is opened and then closes immediately.

Any tips?

Thanks!

service_principal.png
Oscar
Oscar
1 year ago

Hello again,

I understand. Hopefully, they will fix it soon.

Thank you for your guide and your reply!

Ryan Perry
1 year ago

Confirming the same. As of 9/15/2023, this is still an issue.

Andrew Yoder
1 year ago

Hi Matthew-
I think until the client secret expiration issue is resolved, it would be potentially catastrophic advice to use this technique. Some quick research suggests every flow in the environment will fail simultaneously upon expiration of the secret in 2 years. I will not be setting this up for any additional clients until resolved and am going to unwind all connections I’ve made with past service principals.

Dan Barrett
Dan Barrett
1 year ago

Hello Matt, thanks once again for another great article.

Just wondering how this works with ALM when we move the solution into test and Prod?

Dan

Last edited 1 year ago by Dan Barrett
Sandy
Sandy
1 year ago

After reading this comment that you “teach” this, I searched your website for training classes. I didn’t seem to find any, but I’d love to take your course. Can you share a link to purchase it? Thanks!

Craig Stanley
Craig Stanley
1 year ago

Hello Matthew – thanks for the excellent post. Do you have any suggestions on using Service Accounts / Service Principles with SharePoint online in Power Automate Flows and Power Apps?

Nick Parazzi
Nick Parazzi
1 year ago

Hi Matt. Thank you for a very interesting post. From what I can see, this only works with Dataverse, I cannot add a service principal connector for Sharepoint, for instance. What would you do in this case?

Chandra
Chandra
4 months ago

Hi Matt,
Thanks for the post, we are in the process of finding best way to run our Power Automate flows on non-interactive user accounts. As per the below Microsoft Article, if a flow is added to a solution, the ownership of the flow can be transferred to a service principal, But not sure whether this will transfer the ownership of individual connectors(SharePoint, OneDrive….) inside the corresponding flow from personal account to service principal or not..

I am really confused about this, can you shed some light on this for me please.

https://learn.microsoft.com/en-us/power-automate/service-principal-support

Last edited 4 months ago by Chandra
Carlos Lopez
Carlos Lopez
1 year ago

Hi Matt, great article and very clear! Thank you! I have a question: is there a way to use Managed Identities instead of Service Principals?

Syed Obaidullah Ali
Syed Obaidullah Ali
1 year ago

Hi Matthew, shouldn’t we use Service Accounts instead of Service Principals in Power Automate?

Ryan Perry
1 year ago

Hi Matt. Great content – one area I was hoping to find is best practices for working with Service Accounts and ALM. If using Devops pipelines, one can run the import as a service principal, but as far as I am aware, there is no way to import a solution as a service principal using the standard solution import UI, which means that all of the flows, etc. would be owned by the importing user / service account, not a service principal. Of course, flow ownership can then be reassigned, but that can get tedious. I would love to see a follow up article with your thoughts on ALM best practices with service principals, without having to go all-in on source control, Devops pipelines, etc. The pro-code tooling is a lot to set up for most smaller clients / projects, let alone citizen developers just learning this in their own tenants.

Last edited 1 year ago by Ryan Perry
thomasG
thomasG
1 year ago

Hi Matt,
Great article, thank you! I would like to know though how service principals should be used when the flow (or any other service) is within a solution that is eventually going to be imported to a production environment. I assumed that one would have diferent SPs per environment. So how might I have a flow use the correct SP dependant on which environment it’s in. Hope that makes sense – it’s really bugging me!
Thanks,
Tom

runr02
runr02
1 year ago

Is it possible to use certificate instead of client secret? If so where can I access information on how to accomplish this?