Many people are asking the question, should I use my personal account or should I use service accounts in my Power Automate flows?
Scenarios
Table of Contents
There isn’t really an easy answer to this question. You have multiple ways of working. Time to look at some scenarios.
- A user updates a list item that triggers a flow
- A user updates a list item that triggers a flow and flow updates the item with a status
- A user updates a list item that triggers a flow and flow updates the item with a status after a day.
A user updates a list item that triggers a flow
Imagine I have a flow that is triggered by some update to some data. Do I really care who owns my flow? Remember the flow runs as the owner of the flow and the actions will run as the owner of the connections and in this case my flow doesn’t update any data but it is still important that the process doesn’t depend on me.
For example,
- If I’m off ill. Should the flow still run?
- If I leave the organisation should anybody be able to manage the flows?
This already means that you might want to share your flows with a service account. Even if not many people are interested in your flow today, you might find that one day they will be interested. Most likely this is the day that you aren’t available.
A user updates a list item that triggers a flow and flow updates the item with a status
The same arguments are still relevant if we need to update the triggering item or create a new item.
Important questions however:
- If a flow updates the item do you want to know that it was flow and not you? Maybe …
- If the flow create a new item in a different list do you want to be responsible for that? From an auditing perspective should this list item be owned by you?
In the above two question you might still have wanted to run as a personal account but now a 3rd scenario
A user updates a list item that triggers a flow and flow updates the item with a status after a day
I now have a holiday request system. I create a list in an item and my flow is approved by my manager and the HR manager. The flow does some updates to the list item about a day after I created the request. Do I still want the item updates to be done by myself?
No.
It is probably better to update using a service account so that within the version history I can see which updates I did and which updates my flow did.
Just to be clear I am not saying that service account are always the best option however it is one of the options that should be considered. Service accounts should be considered for both managing/editing flows and running your flows.
Service Account vs User Account
So far I’ve only looked at what is needed from a solution perspective, but there is more to consider.
What happens when someone leaves your business. Do their flows suddenly become obsolete?
Probably not!
If a flow is something that a citizen develop puts together for their personal use ( such as cleaning up emails, or getting alerts specific to them) then there is probably no need fro a service account.
But if you are implementing a business process that should be there for longer than your stay within your organisation then a service account is often a good idea. Also when you send out emails as part of your process, should these emails come from you personally? Are you happy to clutter your sent items with other people’s alerts?
The other thing that can be important is how you deal with Development, Test and Production environments. In development you might run flows as yourself but in production that might not be what you want.
Your thoughts
I would be interested to hear your points of view on this. Please feel free to leave any comments below.
How can an organization allow flow creators to use service accounts without letting them know the accounts password?
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.
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 🙂
Hi Dean, that is indeed a difficult question. I would probably go for a single account unless there is a reason not to.
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.
In this scenario Service Account must have an Office 365 plan for access and execute flow?
Yes, the service accounts need to be treated like any other use account. Also you will need to make sure that the right licences are in place for Flow and/or PowerApps.