5 replies

  1. How can an organization allow flow creators to use service accounts without letting them know the accounts password?

    Like

    • Hi Dean,

      I think it all depends a bit if your talking about Centrally Managed flows or personal small flows. In quite a lot of my projects I’m merely focusing on the larger background processes that do the heavy flow work.Then developing the flow with a dedicated account is probably less of a problem. Imagine if I created a helpdesk system with flow. Would it be a problem if I used an account called helpdesk@mycompany.com when I deploy the solution to production? This is where I could consider to create different accounts for different solutions.

      For the personal flows where you would want the service account to be able to access the flow you can share your personal flow with that service account without knowing the password. So again not a problem.

      Like

  2. For smaller, personal flows that should not be tied to a specific user, do you typically have one service account that many people use, or do you have many accounts, e.g. one for each department/business unit/external system.
    I’m struggling with the balance between simplicity, security and reliability 🙂

    Like

    • Hi Dean, that is indeed a difficult question. I would probably go for a single account unless there is a reason not to.

      Liked by 1 person

    • Hi Dean. This is something we talked about here since we have done service accounts for our web apps for years. We have decided what makes sense for us (won’t work for all) a few things.

      1. All Flows and PowerApps will have at least 2 owners. If someone doesn’t anyone they can share with, then share with our team (the SharePoint/Office 365 Team).

      2. We will use service accounts for all connections that way we don’t have personal accounts that may one day get deleted. This also means our personal accounts (or the accounts of who is making these) does not get access to things that will end up showing up in Search Results for that person or messing up their MS Graph AI stuff.

      3. We will use a Generic Service Account for most access. Once we encounter a place where there is personal information stored (or information that anyone with that specific Generic Account) or security sensitive process should not have access to then we will create another service account specifically for it.

      This has worked ok for us in the past with our web apps so we figured we would carry it over here. Best scenario would be the ability to set a flow to run as the user that is starting the process at runtime but since that is not there we think this will work for us.

      I like this article and the way it is worded as it is pretty much the same discussions we have had here to come up with our process. And I am with Pieter on this – you will have to figure out what works for you as no one size fits all will work for this.

      Liked by 1 person

Leave a Reply to Maurice Vold Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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

%d bloggers like this: