How to scale a flow for enterprise usage?

[Anonymous]

Hi Guys, 

I have developed a Flow to automate our Office 365 licencing request process. The Flow works without issue and as intended, however, I'm very aware that all of the connected services (Forms, SharePoint, Exchange, Approvals, AAD) are very much associated and authenticated against my personal AD account (in its current state).

So my question is, how should a flow be configured and scaled for use in the enterprise? How would it connect to the services it needs without relying on the creator's AD account? Are there any best practices around this? 

Thanks in advance 🙂 

[DLGross]

I think i would recommend creating an Office Group, and then make the Flow a  Team Flow that is assigned to that Group. The Group would containing the people responsible for Licensing and would be granted the appropriate role based permissions to each of the various services/apps.

[Anonymous]

@DLGross - Thanks for the reply. 

Interesting idea, however, I would assume that the account of a group member with relevant licence permissions would still be needed to connect to the services/apps associated with the flow? 

[DLGross]

License and Permissions are 2 different things.

To be compliant, Users must have a license, but this is not checked by many of the services.

The benefit of using a Group is that it eliminates the need to assign permissions to individuals.

[Anonymous]

@DLGross - Thanks, for the details

So I can see that is it possible to assign a group as an "Owner" to a Flow which is good. So let's say hypothetically...

1) I created an O365 group 

2) I added individuals to the group who all had appropriate licences

2) I then grant the group Owner permissions to the Flow

How would I then connect to the associated services embedded in the Flow without using another group members personal credentials? Im guessing its not possible to connect to services/app as a group?

To my mind, the only way I can think of doing this is 

1) Create an AD Service account and assign relevant Flow licences to it

2) Assign the AD Service account as a "Owner" on the flow (in addition to any other existing owners)

3) Connect to the associated services embedded in the Flow using the credentials of the AD service account. 

I believe this approach would allow for the Flow to operate and connect to the associated services and apps without relying on an individual's credentials, 

My goal here is to deliver and deploy a flow which can operate completely independently of an individual's credentials.  I think an AD service account is a way to go but I'm not sure if this is considered best practice in relation to Flow. 

Thanks

Simon

[Anonymous]

Can anybody help here? I'm struggling to understand how a Flow can be deployed in an enterprise environment...

As it stands it looks like there is not a feasible solution. 

[Dorul]

You can create an AD account just for the flows, but i doubt its really needed.

Half of the flows we use were created by me. But if i leave and my account will be deleted, its not the end of the world. The solution is quite simple: save a flow from "Team flows" (with save as, not export) and will have a copy in "My flows". Even if the flow wasnt created by me, the connections will appear with my user. So whoever is leaving, your flows can go on with the next user, no need to create other flows.

I hope thats what was troubling you, but not sure if i was clear enough 🙂

[Anonymous]

Thanks for the reply and I appreciate your suggestion however to my mind it doesn't not seem to be a viable solution in the enterprise because whichever way you cut it you are still relying on an individual's credentials to connect to the services and apps.  And administering that in a large business presents risk especially if the flow is used to provide a user impacting service.  

My feeling is that for flow to a be a viable solution the connections to the services and the apps used in the flow would need to be established using a service account dedicated for the purpose. Therefore irrespective of who starts and leaves in the business, the flow service remains un-interrupted without administration. 

This is the way I have delivered similar workflow solutions to other businesses in the past, but not sure if its the best way to deliver a truly uninterrupted service with Flow? 

[Dorul]

Well, we had an incident, see the link below:

https://powerusers.microsoft.com/t5/Connecting-To-Data/Constant-authentication-issue-with-O365/td-p/...

Everything stopped working without a mail or notification of any kind. So even with an AD account created especially for this, someone still need to check on a daily basis, just to be sure everything works fine. If it happened once, can happen again.

[Anonymous]

Ouch! Thank you for the link, just read through the thread and im getting the impression that this product is not "enterprise ready" and is not as robust as solutions I have used in past such as SharePoint Designer and Nintex 😞 

Would be a huge shame if I have to recommend not to deploy the Flow enterprise-wide due to reliability/scalability issues, as mentioned in the thread you shared, we really can't deploy a flow we have to monitor and maintain and administer frequently.  

[cdc_rich]

Hey I'm curious, what is your experience/opinion in 2022? Is it enterprise ready?