Posted on

Service principals vs service accounts: Which one should you use for Power Automate flows?

colorful toothed wheels

Power Automate allows you to automate workflows across various applications and services. However, when you create a flow, you need to decide how to authenticate and authorize it to access the data sources and actions it needs. This is where service principals and service accounts come in.

Service principals are special types of users that represent an Azure AD application. They have a system administrator role and use a client secret (a permanent password) to connect to data sources such as Dataverse. Service accounts are regular user accounts that have a username and password. They can be assigned different roles and licenses depending on the flow’s needs.

Recently, I posted How to use service accounts in Power Automate flows and avoid common pitfalls. Check it out to do a deeper dive on just service accounts.

So which one should you use for your Power Automate flows: service principals or service accounts? Here are some pros and cons of each option:

Service PrincipalsService Accounts
Pros:Pros:
– More secure as they do not expose username or password– Easier to set up and manage
– Do not consume a license as they use an application user account– Can be assigned different roles and licenses for different flows
– Can perform actions on behalf of organization users who trigger the flow– Can access more data sources and actions than service principals
Cons:Cons:
– More complex to configure and troubleshoot– Less secure as they expose username or password
– Limited to data sources that support Azure AD authentication– Consume a license for each service account used in a flow
Table comparing the pros and cons of Service Principals and Service Accounts

As you can see, there is no definitive answer to which option is better for your Power Automate flows. It depends on your specific scenario, requirements, and preferences. However, some general guidelines are:

  • Use service principals if you want more security, less licensing costs, and more flexibility in performing actions on behalf of other users.
  • Use service accounts if you want more simplicity, more data source options, and more control over roles and licenses.

This post has explained the high-level differences between service principals and service accounts to consider when building flows in Power Automate. For more information, please refer to these resources:

Posted on

How to use service accounts in Power Automate flows and avoid common pitfalls

Do you want to automate your workflows with Power Automate and make sure they can last for years to come? If so, you need to pay attention to how you share your flows and how you sign into the services that you use in them. Using your own user account may seem convenient, but it can also cause trouble if your account gets changed or deleted. In this post, I will show you two examples of what can go wrong when you use personal accounts in Power Automate flows and how to avoid them by using a service account instead.

Consider these two scenarios involving Power Automate flows that connect to different services:

  • Bob creates a flow that triggers when a new item is added to a SharePoint list and sends an email alert to his team. He uses his own user account to create the flow and does not share it with anyone else. A few months later, Bob quits his job and his account is disabled. The flow stops functioning because the connection is lost and no one can access or edit it. The team does not receive any email notifications and has to manually monitor the SharePoint list for new items.
  • Carol creates a similar flow as Bob but she shares it with her colleague Dave as a co-owner. However, she still uses her own user account to authenticate to some connectors or actions within the flow, such as sending emails from her Outlook account. A few months later, Carol resigns from her job and her account is deactivated. The flow still runs but some connectors or actions fail because they rely on Carol’s credentials. The team receives incomplete or erroneous email notifications.

These examples demonstrate the risks of using personal accounts in Power Automate flows. And both scenarios could have been avoided if Bob and Carol had used a service account to create their flows and connect to the various services used in the flow. You may end up with broken connections, failed actions, or loss of access otherwise.

So what exactly is a service account? A service account is a special user account that has a fixed license and does not belong to any individual person. Multiple users may know/share the credentials to use the account for building flows. You’ll treat it much like a user account as you provision a license for it then add it to teams, groups, and roles so that it can perform actions a normal user would.

By using a service account, you can make sure that your flows run reliably and securely no matter what happens in your organization or team. Just be careful, as with any shared security asset, not to share a service account’s credentials with too many flow makers. 2-3 users would be the max I would personally consider for redundancy as people take leave and the organization experiences turnover.

Tips for building sturdier flows in Power Automate by using service accounts

  • Create a dedicated service account with a fixed license and assign it the appropriate roles and permissions (site or team membership, shared mailbox member, security group member, etc.)
  • Consider creating multiple service accounts that have access to different environments, teams, sites, etc. to ensure you don’t have one service account with access to absolutely everything
  • Creating the flow
    • Use a service account to create the flow or
    • Use a service account to create the flow and share it with other users as co-owners for more convenient edit access or
    • Share a flow you have already created with the service account as a co-owner (co-owners keep flows after other co-owners leave an organization)
  • Use the service account to authenticate the connectors or actions that you use in your flows, such as SharePoint, Outlook, or Teams. If any single step’s connection belongs to an individual, there is risk that the step will fail if that person’s account is disabled or even if they have authentication issues.
  • Test your flows regularly and monitor their performance and status using the service account
  • Document your flows and their connections and keep track of any changes or updates using the service account

References