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
16 Comments
Oldest
Newest
Inline Feedbacks
View all comments
EZ Otb
EZ Otb
23 days 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
23 days 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
18 days 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
22 days 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
22 days ago

Hi Matthew

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

Kind regards

Melanie tully
Melanie tully
21 days ago
Reply to  Native Nass

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

Mark Slosberg
22 days 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
14 days ago

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