Setup a Service Principal in Power Automate
Every now and then I get the question on how to setup a Service principal in Power automate. This blog post intends to explain this common request.
First of all, we have to talk about what a Service Principal is and why we should use it.
What is a Service Principal?
The Microsoft docs do describe a Service Principal very well. They write the following:
To access resources that are secured by an Azure AD tenant, the entity that requires access must be represented by a security principal. This requirement is true for both users (user principal) and applications (service principal). The security principal defines the access policy and permissions for the user/application in the Azure AD tenant. This enables core features such as authentication of the user/application during sign-in, and authorization during resource access.MS Docs
This basically means that a service principal is defining which access and permission an application that tries to access a resource within Azure has. The docs do also describe the three different types of service principals. We will only take a look at the type of Application.
Why use it?
There are three main reasons to use a service principal.
- A service principal decouples the Flow from a user and solves the dependency to it. So when a user get’s inactivated or deleted the flow does not lose access.
- We can use a different service principal per area/integration. This makes it possible to give the certain application user only the needed access within Dataverse. Which allows us to use the princible of assigning only the minimal permissions.
- It is possible to use different service principals for different environments which makes sure that we not by mistake access the wrong environment.
In Power Automate it is very tempting to just use the connection which uses a user principal that will be automatically created. Because of the mentioned reasons, it is a good idea to change the connection to a service principal connection.
Now that we know what a service principal is and why we should use it we can take a look at how to set one up.
Create App Registration
First, we have to create the App Registration in Azure AD.
To be able to do the following steps you need certain permissions within the desired Azure subscription. Those are documented on Microsoft Docs. In general, the owner of a subscription is allowed to create App Registrations within the given subscription.
To do so we
- log in to the Azure portal
- open Azure AD
- navigate to App Registrations
- click on “New registration”.
In the next screen you can give your App Registration a good name. I took “Service Principal Demo”. All the other parts can be left as the default is. Click on “Registe” to create the App Registration.
After you have created the App Registration you will come to the overview. Here you can copy parts of the information you will need later.
Now that the App registration is created we can configure everything we need.
Certificate & secrets
We navigate to “Certificate & secrets” and click on “New client secret”.
On the next screen you can give your secret a name and select a period how long it should be valid.
If you need a secret which is valid longer than 24 month you can take a look at my other article about just that.
Make sure to copy the value of the secret and save it somewhere safe. It will only be shown once.
Last thing to configure is the API permissions. The App registration needs access to the Dynamics 365 API.
To configure this we navigate to “API permissions” and click on “Add a permission”.
In the upcoming side pane select “Dynamics CRM” as the service you’d like to add permissions to.
On the next page select “Delegated permissions” as well as “user_impersonation” and click “Add permissions”.
Add App Registration to Dataverse
Next step is to register the App registration to Dataverse so that it get’s the right access.
To do so we navigate to the power platform admin portal, navigate to Environments, open the desired environment by clicking the name and go to settings.
On the next page we open the settings page for “Application users”.
There we click on “New app user”.
On the side pane which opens you have to select the desired Business Unit from the dropdown as well as the needed security role(s) and add the app we have created. To Add the app click on “Add an app” and search for the app registration you recently created, select it and click on “Add”.
When you have configured everything you are able to press the “Create” button.
Configure Service Principal in Power Automate
Last step to setup a Service principal in Power automate is to actually use it in Power automate.
We go to the maker portal, open a solution and create a new automated cloud flow.
Give a saying name to the flow, select the Datavere “When a row is added,….” as the trigger ad click on “Create”.
On the Flow edit page, which opens, you click on the three dots and select “New connection reference” in the context menu.
The trigger itself changes, there you have to click on “Connect with service principal”.
Again the trigger changes and gives ou a form where all the information needs to be registered.
You will need:
- Connection name
- Client ID – Which you get from the App Registration overview in Azure
- Client Secret – The Secret value you copied earlier
- Tenant – Which you get from the App Registration overview in Azure
After you have filled in this information you can press “Create”.
To check if everything worked as expected you can open the context menu of the trigger again.
Congratulations you have successfully setup a service principal in Power automate.
The setup isn’t very complex if you know which steps to execute.
Hope this article helped you. Please let me know if you have any problems.
You can also subscribe and get new blog posts emailed to you directly.
This is a great guide, thanks Benedikt. But how do you migrate the service principal connection across environments without having to reestablish it?