Own and run Power Automate cloud flows with Service Principal
What is a Service Principal?
In my previous article, Set up Service Principal in Azure to work with Power Platform, I discussed this topic. Please go and check it out! It not only discusses the Service Principal and (Azure App Registration) topic as a whole, but it also explains how you can set up a Service Principal yourself in your Microsoft 365 tenant.
Today, I will briefly explain the essence of a Service Principal in Power Platform mentioned in a previous article.
A Service Principal is a non-interactive account that facilitates connections to Dataverse and the management of flows. Essentially, this “User” is an Azure App, which is employed within the Power Platform to take ownership of Power Automate flows. It’s important to note that you cannot log in with a Service Principal or interact with it as you would with a typical Azure AD User.
Service Principal - this is a series!
Hey! This is a series of three articles regarding a Service Principal.
- Set up Service Principal in Azure to work with Power Platform – this article shows you how to set up an App Registration in Azure to work with Power Platform
- Own and run Power Automate flows with Service Principal – this article, on the other hand, discusses how to register a Service Principal in Power Platform and how to own and run flows in Power Automate
- Use a Service Principal to run Dataverse actions in Power Automate – the last one of the series discusses how Dataverse actions can run with a Service Principal so users don’t need to use their personal accounts to authenticate.
Work with a Service Principal in Power Platform
We have an Azure App ready – we set it up in this article: Set up Service Principal in Azure to work with Power Platform.
Now, we must connect this Application to the Power Platform. So, how do we do that? I will show you step by step. Follow me!
Register Application User in Power Platform
To start, open the Power Platform Admin Center.
Then, select the environment you want to add a Service Principal to.
Click “Settings” and wait for the page to list all available options.
Now, under the “Users + permissions” choose “Application users”.
On the top of the page, press “+ New app user”.
Choose the registered application user and click “Add” at the bottom.
Choose a Business Unit for a Service Principal and provide a security role. In my scenario, I am assigning the “System Administrator” role because this Application User will manage many flows and tables across Dataverse, but you can granulate the permission by providing only minimum required privileges.
After you save the changes, you should see the confirmation.
Create a solution in Power Platform and a cloud flow
The Service Principal is now registered in Power Platform and can be used. So, how do we use it?
We want our Service Principal to own flows so we don’t have to, and they are not gone when an account owning some flows is deactivated.
Do you remember that you can’t log in with the Service Principal? So, how do we transfer the ownership of flows to the Service Principal account? We use Solutions! Let’s create one.
Then, when a solution is created, create a cloud flow. You will be the owner of it for a second.
Create a cloud flow, like you usually do.
I created a very simple flow. Its content is not the most important thing here.
Change the owner of the cloud flow to a Service Principal
When the flow is ready, go to the newly created flow.
As you can see, the owner of the flow is “Adam Kowalski” – the user I used to create the flow, and this is correct. Now, we want to change the owner. Let’s do that!
Click the “Edit” button for the flow’s information.
In the “Owner” field, choose the application user you registered and hit the “Save” button.
Give the system a second to process the change. If it’s successful, you should see the confirmation. Press the “Save” button again and close the window.
Now, the Service Principal account is the owner of the flow! That’s it!
Summary
I think Service Principals will be very useful for bigger projects to standardize who owns the flows, who runs them, and how to manage licensing for Power Automate cloud flows. If a Service Principal owns all flows, you will not need to worry about when someone leaves the organization and you lose access to some solutions or flows, especially when Makers do not often use solutions. Then, you would need Power Platform admin to provide you with access to orphaned flows. This is why Service Principals (like previously used “Service Users”) are so important, and it’s good to know how to set them up and how to use them.
So, finally, we are at this point where I should thank you for your time and reading this article. Feel free to rate this article and comment if you liked it. If you have any questions, feel free to contact me (via contact@poweruniverse.org), but first, you may be interested in joining a Newsletter. Hmm? (Sign up here) If you already did, wow, thanks, thanks a lot 
Via Newsletter, I am sharing insights into my work, plans for upcoming weeks, and knowledge about Power Platform Universe and the IT world. If you are interested, feel free to join! I am going to send the latest Newsletter to everyone who enters!
See you!
Daniel Ciećkiewicz
I am a Senior Power Platform Consultant focused on Dataverse, Power Apps, and Power Automate. I was also a Team Leader responsible for the Power Platform Team and their development paths.
In my private life, I like video games, sports, learning & gaining knowledge, and a taste of good Scotch Whisky!
Ooo, I almost forgot, I love our Polish Tatra Mountains!
Power Apps Licensing Explained
Power Apps Licensing – this is something every Power Platform expert must know. In this article I will walk you through the cons and pros of available plans.
Understand Delegation in Power Apps
In this article I will walk you through delegation in Power Apps and I will show you many interesting concepts how to work with delegation and understand Delegation in Power Apps!
Connection vs connection reference in Power Platform
In this article I will tell you what is the difference between connection and connection reference in Power Platform. It is very good to know the advantages.
Overview of a Tenant Isolation in the Power Platform
What is Tenant Isolation in the Power Platform? How does it work and how do you know it will be good for your organization? Check the article!
The most interesting Power Platform features of 2024 – Wave 1 update
Do you want to know what updates are coming in 2024? This article will tell you more about incoming updates for Power Platform in Wave 1.
Use a Service Principal to run Dataverse actions in Power Automate
Do you want to learn how to use a Service Principal to work with Dataverse actions in Power Automate? This article is for you. Check it out.
The most interesting Power Platform features of 2024 – Wave 1 update
Do you want to know what updates are coming in 2024? This article will tell you more about incoming updates for Power Platform in Wave 1.
Overview of a Tenant Isolation in the Power Platform
What is Tenant Isolation in the Power Platform? How does it work and how do you know it will be good for your organization? Check the article!
[…] Own and run Power Automate flows with Service Principal – this article, on the other hand, discusses how to register a Service Principal in Power Platform and how to own and run flows in Power Automate […]
still not sure what giving ownership to a Service Principal actually does. The moment you put a solution in place, all it’s contents are accessible beyond the current user. What does assigning ownership to the Service Principal actually do?
If a User who owns flows leaves, flows and apps owned by this User become orphaned. There is always an owner; it doesn’t matter if you use solutions or not.
Trust me, this is a big problem in bigger organizations where you manage a Power Platform with up to 1000 Makers creating stuff in the Power Platform. They don’t use solutions and don’t know the best practices. Someone leaves the company, and all the work is unavailable for other people; they can’t access it or modify it, and if it fails, then they realize something is wrong. Then the administrator must intervene. This is a common thing.
Having a Service Principal set up and owning flows for a team would greatly help in those cases.
Hi Daniel,
We are just about to make the Service Principal the owner on our flows. So I’m used to the old way of authenticating with a user account and sharing the flow.
The flow will be visible for Makers if it’s included in the solution.
So:
You can also add users as co-owners before.
You don’t authenticate using PS. Just set up a Service Principal and share flow after it’s created. The CoE Starter Kit also includes tools for adding owners/co-owners to flows, but that’s not the topic for today.
Hi Daniel,
can you please clarify on below:
It’s important to note that you cannot log in with a Service Principal or interact with it as you would with a typical Azure AD User.
so if you can’t login to service principal, how do you manage? and does the user still need power automate premium licence to be able to use premium connectors?
Thanks
Users must have a premium license assigned. Yes, they need a license when they work with Power Automate and use it.
The service principal is distinct from a service user in that it operates without a login and password, providing a unique functionality.
Service Principal is an app registration on Azure that can do/take actions that a normal user can do, but it’s not a user in a meaning of that.
You can own and run Power Automate flow by adding this app registration (Service Principal) to the environment and providing proper permissions.
Then, you just select this “user” in an owner box in Power Automate flow.
As for managing the flow, like other users asked, please share it after it was created (because some real users created it, so you can add co-owners). Or you can just include the flow in the solution so every System Customizer Maker within the environment can work with it — at least the System Customizer role must be assigned.