Power Platform Community Forum Thread Details

Hi Everyone,

I have a large number of Power Automate flows that integrate with both Dynamics and other parts of the Power Platform (particularly Teams). We have a Service Account (User level account) that runs these flows as required, but I am wondering if using a Service Principal account is a better / more appropriate way to approach this?

Setting up a Service Principal account seem relatively straightforward but are there any pitfalls to this - can this be reversed if required?

Thanks in advance!

Categories:

Governance & administering

One of them main difference between having your flows owned by a service principal vs a service account (a normal ad user account that is not a real user) would be the licensing of the flows.

My understanding is that you cannot assign a license to a service principal, and hence, power automate licenses owned by a service principal would then have to be licensed on a per-flow basis rather than per user. This could get costly if you have many Flows (especially significantly more than you have users). Yet MS documentation is somewhat vague on this, as some blurb about Flow co-owners could workaround this licensing issue (e.g. by assigning a service account as the co-owner of the flow, then assigning a power automate license to that user account, which kind of defeats the purpose of the service principal owning the flow). Source: PA licensing

Another area where you may or may not yet see tangible benefits would be when enabling/turning on flows (e.g. as part of an ALM process). For the service principal to turn on any Flows, any connections used by these flows need to be shared with that service principal. At this current time, there is no automated way to create connections (or rather I'm not aware of a way for a service principal to create a connection), hence the creation and the sharing of a connection would have to be a manual process done using a normal user account. This is why currently any ALM that attempts to enable/turn on flows needs to use impersonation to turn on any flows, and cannot use a service principal directly.