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.
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
Michael,
I appreciate the detailed response. It would be great if I could pin comments to the top of the list. This one is very helpful!
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?
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?
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?
Niels,
Go to Power Apps Studio then click More… on the left menu, then select Connections. Search for the connection click Edit update the secret.
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!
Oscar,
Unfortunately, it’s a user-interface bug. The switch account option should pop open a new menu. We need Microsoft to fix it 🙁
Hello again,
I understand. Hopefully, they will fix it soon.
Thank you for your guide and your reply!
Confirming the same. As of 9/15/2023, this is still an issue.
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.
Andrew,
You can extend the service principal lifespan to whatever you wish with this article:
https://crmtipoftheday.com/1404/app-secrets-that-last-longer-than-2-years/
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
Dan,
You have to setup an Azure DevOps pipeline to move the solution using the service principal. I teach this subject but I do not have any articles on it currently.
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!
Sandy,
Firstly, here’s a DevOps tutorial that I did at a user group last year you might find handy. Let me know if it’s a good start for you. It covers a lot of the basics but there’s a bit more to it.
https://m.youtube.com/watch?v=wQe7n62RRNU
At the moment, I don’t currently have a course. I’m doing live instruction through my employer for our clients (see LinkedIn for the company name). Maybe I should record some videos 🤔
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?
Craig,
What specifically would you like to know?
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?
Nick,
Unfortunately, I would stick to only Dataverse at this point. I haven’t been able to make SharePoint work.
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
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?
Carlos,
No. Not that I’m aware of.
Hi Matthew, shouldn’t we use Service Accounts instead of Service Principals in Power Automate?
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.
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
Is it possible to use certificate instead of client secret? If so where can I access information on how to accomplish this?
Runr,
No you may not use a certificate here.