Copilot for Microsoft 365 Tech Accelerator
Feb 28 2024 07:00 AM - Feb 29 2024 10:30 AM (PST)
Microsoft Tech Community

Best practices for Power Automate with service account

Iron Contributor

We had a colleague leave who had their work email address and account connected to MANY Power Automate flows, SharePoint, OneDrive, Forms, Excel, etc.


We are looking to create a recommendation / best practices for a single account that will be used by the I.T. department for use in Power Automate, etc.


We will have colleagues in the I.T. department have access to SharePoint sites (maybe a security issue? do we EACH get our OWN accounts then?) and Power Automate


We'd have to have it setup as an email enabled account so we'd have to pay instead of a service account.  

Other thoughts?

36 Replies
same question - we are starting to create more flows and they are all coming from my account, even when we use the 'send as' option. The 'approval' is routed corrected, shows the correct 'from' email but in the Teams approval tab, it shows sent from my a mail-enabled, licensed user the only option?
Try this : Setup a Service Account and assign it an O365 License
- Create new Flows or import existing Flows into the Service Account
- Share the Flows with the Authors (so they can update the Flows from their own account but it continues to run as the Service Account)
- email will come from the Service Accounts email address
I've read here
that going with service account to run flow requires us to acquire and assign per flow license. Is it correct?
As I understand it, yes 1 per flow license is required for each flow running under a service account.
This is really a concern. What about flows running once a week or even less? It's convenient to have service accounts running flows to reduce disruption and simplify management. It's a non-sense to force something like this
I agree if you have low frequency flows, the it could get expensive.
Per Flow Licensing costs are here. 5 Flows for $US100/month.

LogicApps have a consumption pricing model that can be very low cost for low frequency flows.

Still very cheap in comparison to other workflow solutions
Hello, Are you sure about the "5 Flows for $US100/month"? That was my 1st understanding from pricing page but my Microsoft account manager told me differently. He says that it is 1 Flow for $US100/month, and minimum buying of 5 licenses.
I'm sad that Microsoft with this is somehow pushing us to logicApps
We had a long discussion with Microsoft on this topic. They are internally not clear what's the correct license - but after a lot of meetings - they are sure: You need a per flow license which is a minimum of 5 licenses á 100$.
Please see the following documentation:
Thank you. do you confirm that it is 100$ each per flow license, with a minimum of 5 licenses to buy?
Yes, correct.
Technically speaking, it is also working with just a per user license, but this is from a licensing perspective not correct.

I can't see how MS can force us to use a the Per Flow licensing model instead of a Service account that has a Per User license assigned. In our scenario we create a few account with an E3/5 license and assigne them a Per User license. The accounts are then used by a select few to create any Automated or Scheduled Flows that have business impact. Flows that are for pure personal productivity, are created by the end users personal account. The hard part is keeping up with what flows have business impact vs personal flows.

@Steve Knutson  I disagree here, Steve.

The article states:
"The service account is used by many users. In this case, it is recommended to assign a per flow license to the flow to ensure any new users adding to the account are automatically compliant."


It looks like a recommendation to make Microsoft licence compliance easier but it doesn't seem like a strict functional requirement that will block you. 

Meaning that it shouldn't break your flows if you don't follow it, it seems to be worded as a recommendation, not a rule.

But I might be wrong, haven't traversed this yet. Keen to hear from someone who actually went down this path and has a solution in production that goes through this scenario

I'm with you here. I don't think that Microsoft is forcing anybody.

The wording on their post is "[if] the service account is used by many users... it is recommended to assign a per flow license to the flow to ensure any new users adding to the account are automatically compliant."

"Recommended" and "required" have vastly different implications.
In this updated document - Microsoft is thinking - that the service account is a shared account with many users that they have access to it. In reality, only the IT has access to the service account. What about that? I am really not happy with this confusing licensing model and each person with which we talking about that topic has another opinion.

The Information you shared above is great. I have been reading all you shared here. In this you explained everything very well. If i want any further guideline we will contact you here

Hi @jjdev-nz

We do exactly the same thing in our organisation. We created a normal user (not a service account in MS terms) equiped him with an E3, dynamics 365 license (for premium connectors) and a PA per user license. Then we migrated all business critical flows to this user and share the individual flow with the devs/owner of the flows for ajdustments. The user who owns the flows is managed centrally by a few users in the IT department.

This user only owns flows in a dedicated productiv environment where only he and the IT department is able to create any flows or apps.

For power apps we use additonally power apps per app license.

We came up with this solution/idea after reading the following part of "Establish an environment strategy" documentation from microsoft:



But I'm still confused if we are acting correlty in the boundarys of microsofts power automate licensing.

@LimeLeaf it is a little bit like Schroedingers Cat. Nobody knows :D. Also Microsoft internal is not shure what is the right solution.