Jan 04 2022 01:19 PM - last edited on Nov 09 2023 11:09 AM by
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?
Jan 10 2022 12:53 PM
Jan 24 2022 02:56 PM
Mar 23 2022 09:09 AM
Mar 23 2022 12:19 PM
Mar 24 2022 01:06 AM
Mar 24 2022 11:51 AM
Mar 25 2022 12:38 AM
Mar 27 2022 11:07 PM
Mar 28 2022 12:30 AM
Mar 28 2022 03:33 AM
Mar 30 2022 01:20 PM - edited Mar 30 2022 01:22 PM
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.
Mar 30 2022 01:59 PM
Apr 04 2022 02:17 AM
@SteveKnutson 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."
(Source: https://docs.microsoft.com/en-us/power-platform/admin/power-automate-licensing/faqs#i-have-multiple-...
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
Apr 04 2022 02:20 AM
Apr 04 2022 12:21 PM
Apr 06 2022 09:59 PM
Apr 06 2022 11:14 PM
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 https://techcommunity.microsoft.com/t5/office-365/best-practices-gosloto-for-power-automate-with-service-account/td-p/3052046
Apr 13 2022 01:06 AM - edited Apr 13 2022 01:22 AM
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: https://docs.microsoft.com/en-us/power-platform/guidance/adoption/environment-strategy
But I'm still confused if we are acting correlty in the boundarys of microsofts power automate licensing.
Apr 13 2022 01:42 AM
@LimeLeaf it is a little bit like Schroedingers Cat. Nobody knows :D. Also Microsoft internal is not shure what is the right solution.