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 Azure
• Configure API Permissions For The Application
• Create A Secret For The Power Platform Service Principal
• Setup An Application User For A Power Platform Environment
• Run 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:
- Connection name: Power Platform Service Principal
- Client ID: found on the Azure application’s overview screen
- Client Secret: found on the Azure application’s certificates and secrets screen
- Tenant: found on the Azure application’s overview screen

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

Did You Enjoy This Article? 😺
Subscribe to get new Power Apps articles sent to your inbox each week for FREE
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.
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,
I agree, that sentence is confusing. I did an edit to make the explanation clearer. Please refresh my website in a few minutes to see if my new explanation is better.
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
EZ,
Yes, I believe you can set this up for the SharePoint REST API but unfortunately I did not prepare the setup steps 🙁
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!
Kathyrn,
For SharePoint I would suggest using the Microsoft Graph API. You can set site permissions through Azure AD to limit what the registered app can do. Login is secured using a client secret.
This article does an OK job of explaining the general concept. I’ve done SharePoint actions using the Graph API before and it works well.
https://ashiqf.com/2021/03/15/how-to-use-microsoft-graph-sharepoint-sites-selected-application-permission-in-a-azure-ad-application-for-more-granular-control/
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?
Rohit,
If the flow uses premium actions a per flow license will be required. Flow actions are based on who runs the flow. A service principal is not a user account so the license type must be per flow.
Hi Matthew
How is licensing addressed concerning this service principal when using premium connectors ?
Kind regards
I’d be interested in the licencing too we have E5 (gov tenant)
Native,
Here’s the documentation on licensing:
https://docs.microsoft.com/en-us/power-platform/admin/api-request-limits-allocations#additional-details
I believe the service principal requires a per flow license since it is “not a user account” by definition. Service principal API requests have their limits accrued to the non-user license pool. The limit differs for each organization. If you need more flow runs you can purchase an add-on. But as of this writing they are not really enforcing limits until detailed reporting is available on usage.
Native,
Here’s the documentation on licensing:
https://docs.microsoft.com/en-us/power-platform/admin/api-request-limits-allocations#additional-details
I believe the service principal requires a per flow license since it is “not a user account” by definition. Service principal API requests have their limits accrued to the non-user license pool. The limit differs for each organization. If you need more flow runs you can purchase an add-on. But as of this writing they are not really enforcing limits until detailed reporting is available on usage.
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?
Mark,
My apologies, but I primarily work with Dataverse and SharePoint so I do not know the answer to your SQL question. Here’s what I found in the documentation for SQL service principals: https://docs.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-service-principal?view=azuresql
I think this is coming to more connectors in the near future, fingers crossed for SharePoint!
Ben H,
Very interesting link you’ve shared. Thanks for the info. Fingers crossed.
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.
Nate,
I have not tried using this in a cross-tenant scenario. Sorry, but I cannot answer your question.
Is service principal supported for SharePoint Online and Outlook 365 triggers/ actions?
Jatin,
Sorry, I do not know the answer to this question.
If I created “Service principle connection reference” , Only I can see it and use it. How it can be made available for all users?