Flow Ownership
In my recent articles, Notes on Flow Ownership and Flow Execution Ownership I discussed in whose name the different types of flow are run. Instant flows run in the name of the user who triggers them as “Run-only” users. By default, automated and scheduled flows run in the name of the primary owner of the flow, though for Dataverse triggers, this can be changed for automated flows via the “Run-as” option in the trigger.
No matter in whose name the flow runs, the account must be active. This is particularly important for the primary owner of automated or scheduled flows. If the primary owner leaves the organisation, or if the flow uses premium connectors and the primary owner’s Power Automate license is removed, the flow will stop running.
Consequently, flows (including instant flows) should be owned by a service rather than individual users. By service, I am referring to a service account or service principal. Let me explain more.
Service Accounts and Service Principles
Service Accounts
A service account is simply a standard Entra user account that isn’t assigned to an individual user, but allocated to a service. It has a username and password, just like any other user account, and it can have multifactor authentication. The service account is assigned the necessary licenses and permissions to perform its function.
A service account can be made a co-owner of a flow and assigned as the primary owner of a flow. Service acconts can be created individually for each flow, but for premium flows this would be expensive, as each service account will need to be licensed. It is better to group all the flows for the same solution together with the same service account, or even have one service account across a tenant.
A service account can also be used in flow actions to connect to services and data sources.
Service Principals
A service principal is similar to a service account but doesn’t have a username or password. Instead, it has an application ID and a secret to authenticate and access resources or APIs securely.
Service principals are created in Azure and when used as a connection, they allow flows to access services without requiring direct user authentication or needing a license assigned. For this reason, a service principle is more secure than a service account. A service principal can be used as a connection for Dataverse.
Here is a really good and amusing video from 365. Training that explains how to create and enable a service principal in your environment: How to Create and Use a Service Principal in Power Automate. The screenshots below show how to add a service principal as a connection.
A key difference between a service account and a service principle is that a service principle doesn’t have an identity. It can’t have a mailbox or be assigned a premium license. A flow cannot be created by a service principal, but a service principal can be made the primary owner of an existing flow.
Because a service principal can’t have a license assigned to it, if the flow has premium connectors, for a service principal owned flow to run, the flow itself will need to be assigned a per-flow premium license.
Exporting and Importing Solutions
When you export a solution from one environment and import it into another, the ownership of the flows within that solution change to the user performing the import. For example, if Jim owns the flows in a solution in a source environment and Carole logs on to export and import the solution into a different environment, Carole becomes owner of those flows in the new environment. This means that the automated and scheduled flows in the new environment will run in Carole’s name.
Connection references are solution aware, but connections are not. When importing a solution, the user is prompted to assign a connection for the connection references. If one doesn’t already exist, a new connection can be created. This ensures that the necessary permissions and access rights are configured in the new environment.
It’s helpful to know when to use a service account and when to use a service principal, in the context of creating flows and exporting/importing solutions into a new environment, so I’ll cover that next.
The Guidelines I Follow
OK, to summarise what I covered earlier, and a few additional items, here are the guidelines I follow on building, exporting and importing flows.
Building Flows
First of all, it can’t be stated often enough, always build flows from within a solution! This means the flow will be automatically added to the solution together with connection references and other components. This is important as it can be problematic adding flows to a solution at a later time
Layering solutions, particularly if a solution would otherwise contain a large number of different components, can be useful. However, if you do this, keep apps and flows in the same solution. This is because flows should be associated with an app to avoid additional licensing. This is particularly true for instant flows that run in the user’s name. An instant flow that uses premium connectors will be covered by a user’s premium Power Apps license if it is associated to the app that triggers it.
Use a service account to create your flows and create connections. If a flow has been built using another account, make the service account a co-owner and the primary owner of the flow.
Create connection references in the name of the service account and remove connection references for individual users.
If you are using ALM and have separate instances of SharePoint for dev, test, and prod, the service account connection reference will need access to all three instances. An environment variable within the flow action can point at the correct instance.
If you are using Azure resources or need to access APIs that require application-level permissions rather than user-level permissions, then use a service principal. Make sure you register the service principal for both the environment you are using and the environment to which you will be exporting. How to do this is covered in the 365. Training video link above.
Exporting the Solution
When exporting the solution, if you are moving the solution to test or prod, then it should be a managed solution. I recommend being logged on as the service account when doing this.
Importing the Solution
When importing a solution into a new environment, do this when logged on as the service account. This provides continuity of flow ownership because the service account will be the primary owner of the flows in both the export and import environments. You can re-create connections using the service account credentials when importing the solution, if they don’t already exist.
Bear in mind that not every connection reference in a flow may be in the name of the service account. For example, if a flow contains a ‘send email’ action that needs to use a different account, you will need to select the connection or sign in with the appropriate account to configure appropriately when importing the solution.
Any flow to app associations should have transferred over with the solution, but if the app is in a different solution, then this may not be the case, so if necessary, in the imported solution, re-apply any associations that have been lost.
After following the above guidelines, the flow ownership and connection should be the same in both the export and import environments.
Finally, share the instant flows with users together with any apps.
Remember, it doesn’t do any harm to go into the imported solution and look at the flows if you want to check the flow ownership and connection are using the correct account. The flows in both environments should also be the same in terms of their on/off status, but again it’s worth checking to confirm.
Service Principals
Now you’ve probably noticed that in my recommendations above, I’ve not mentioned service principals.
As I mentioned earlier, service principals can be made the primary owner of flows. However, because it’s not possible to log on as a service principal, solutions cannot be imported in the name of a service principal.
This means that although the flows may be owned by a service principal in the export environment, in the import environment, the primary owner of the flows will be the account that imported the solution. You will need to open every flow in the new environment and change the primary owner back to the service principal.
An additional issue mentioned earlier, is that licenses can’t be assigned to a service principal. This means that each flow with premium components will need a per flow licensing assigning.
Due to the above, limitations, my personal view is that there is little benefit in making a service principal the primary owner of a flow. instead, I set the primary owner to be a service account.
As I mentioned earlier, service principals can have connection references to data sources such as Dataverse. However, my view is because a service account should be set as the owner of a flow, use the service account for connections too. I generally only use a service principal when using the service account isn’t an option.
The exception to this rule is when the flow requires exceptionally high request limits. Service principals are allocated higher limits than service accounts, so for specialist flows that run very frequently or make lots of API calls, it may be worthwhile using a service principal as a connection reference. See here for more details.
Licensing
Finally, a word about licensing.
Using a single service account across a tenant would require it to be licensed once, but multiple service accounts where the flows use premium connectors, would get expensive, as each service account will need a premium license.
Service principals are created at zero cost but remember that each premium flow that a service principal owns will need its own per flow license. Depending on the number of flows you have, this could be a cheaper option, or more expensive.
Summary
That concludes my recommendations. Let me know what you think. If you have a different approach, particularly on the use of service principals, then be sure to let me know about it in the comments below.
For more info on how to manage user access to environments, see my blog post here.