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


3 Replies to “How to use service accounts in Power Automate flows and avoid common pitfalls”

  1. Thanks for you article

    You can also create a M365 group and share to the group the workflow. This way you can easily manage who has access to workflows in a centralized way.

    That said, I believe MS missed something regarding the security in power platform. Mostly everywhere else in the M365 platform, AAD is used to define strong permission model with application identity accounts.

    With powerautomate, this is not possible:
    * http triggered flows are not securable
    * calling most of actions require individual accounts, not application accounts
    * http action using oauth to call SP REST actions requires passing certificates as B64

    … lot of work to do to make PA industry ready

  2. Great post, and something I’ve definitely not followed the best practices on myself in the past. Hey your Docs link (2nd reference link) lands on a 404 and I couldn’t quickly find the right page, maybe MS has removed it.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.