Update 18/09/2022: Microsoft is working towards service principals, more info will come soon in a separate blog post. Service Accounts have some disadvantages in an enterprise scenario like licensing costs, …
When you’re building Flows & Power Apps in the Power Platform, you are probably creating it with your personal O365 account instead of using a service account. This means that you are currently the only owner of this Flow. This is not an issue if you’re building it for your own personal productivity.
If you’re building them with the purpose of building a business application, it is an issue. Or at least, it can be an issue if you don’t take additional actions.
Building business applications with the Power Platform is perfectly possible. Do you already know that you can create environments in the Power Platform?
Yes? You can continue reading this blog post without issues. If you haven’t heard about environments yet, I recommend you to first start reading my blog post about environment strategies. Otherwise, it will be difficult to understand.
Let’s imagine that you created an expense approval flow for the HR department.
The Flow is not for your personal productivity. This means it should be created in an environment other than the default environment.
Let’s create the flow in the environment “HR DEV”. After you’re ready with your business application, you will move it to the “HR PROD” environment where the business can use it. If necessary, you can create an extra environment called “HR UAT”. This UAT environment is only necessary when you build complex solutions in the Power Platform.
A very nice article about environment strategies can be found here.
You are the owner of the flow, because you’ve built it. Let’s imagine that you leave the company. The day that IT removes your O365 account within AD, the Flow has no owner anymore.
If the flow was part of a business process, it would have been better if the service account was the owner of the flow.
Another advantage is that the flow is isolated from normal accounts. The IT department, who manages the service account, always has access to what was built. If the HR department asks for extra features in the future, or one of your Flows or Power Apps returns an error, IT can easily check the problem using the service account.
Another advantage of using service accounts, is that you can protect your UAT and PROD environments by creating separate service accounts for them. Of course there is an extra cost, but when using business critical solutions, it is recommended to protect them.
For the example of HR, this means that your HR UAT and HR PROD environment both are only accessible by one and their own service account. IT can use these service accounts to import solutions from HR DEV to HR UAT or HR PROD.
Because DEV environments are also accessed by citizen developers and they are not business critical (they are important but you can’t interrupt the business from working), you can considerate to only use one service account for all DEV environments. This DEV service account should be accessible by IT. Citizen developers can use their own personal O365 account to build solutions in the Power Platform.
If you’re interested in how this service account sharing Flow is built, you can always read my tutorial about sharing Power Apps and Flows with service accounts.
Also see Microsoft’s documentation about environments & service accounts.
Thanks to TestLodge for the featured image about Application Lifecycle Management.
