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.

  1. 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
  2. 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
  3. 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!


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!

About the author

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!

Top 3 articles
Newest articles
These May also interest you:
5 2 votes
Article Rating
Notify of

Newest Most Voted
Inline Feedbacks
View all comments

[…] 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 […]

Juan Larios
Juan Larios
3 months ago

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?

Would love your thoughts, please comment.x