Power Apps Service Accounts in Environments Best Practices

[DS2]

Hi All,
I have two questions surrounding service accounts and Power Apps if anyone has some best practices they could share.
We use service accounts for our environments and our environments are usually in the format of DEV, QA and PROD
For example, we have a premium environment set of 3 that allows premium connectors, SQL and Dataverse use and it may follow a naming convention as so:

Premium-DEV environment for development
Premium-QA environment for testing
Premium-Prod environment for production

These three environments would have Power Apps within them. For an example, let's say that a Power App named Marketing Pictures exists in all of these environments.
The way we are doing things right now, that Marketing Pictures App would have 3 service accounts, one for each environment, where the service account is the owner of the Marketing Pictures App, with a naming convention of:

service.MarketingPictures-DEV (in Dev Environment)
service.MarketingPictures-QA (in QA Environment)
service.MarketingPictures-Prod (in Prod Environment)

My questions about best practice\best way forward are as follows:

1) Security roles: What security roles should these service accounts have? If you're working with Dataverse, usually the account that is the owner of the App requires at least System Customizer, but this role allows other access within the environment o the App. Same with Exporting and Importing the App into different environments (DEV > QA > PROD). This usually requires the System Administrator role, but then the service account can do anything within the environment including modifying Power Apps that aren't their own.
2) Security of passwords: We sometimes use third-party developers to help with actual code needed in the low-code Power Platform, or they may build an App for us. We provide the service account passwords to them so they can develop in the respective environments. For password security, is there some better way than providing the third-party devs with the passwords to the 3 service accounts and then changing those passwords (and all the connections!) for within the 3 environments?

[BCLS776 · Accepted solution]

It sounds like you recognize the risks that come from sharing passwords to service accounts that may have System Admin level access.

A far better practice: create separate accounts for third-party or internal developers with least privilege to perform their work. Then, as flows/apps are constructed add the service account as a co-owner to each. You can do this through a Power Automate flow that runs daily and does this automatically. 

Hope that helps,

Bryan

[DS2]

Thanks, @BCLS776 - very helpful. When you say "Then, as flows/apps are constructed add the service account as a co-owner to each. You can do this through a Power Automate flow that runs daily and does this automatically," can you please elaborate a little? What would the daily Flow do? Would it enumerate all Flows and check membership and then add the service account as co-owner or something else? Much thanks!

[BCLS776]

This YouTube video will walk you through using the functionality: https://www.youtube.com/watch?v=-ZWm4VGwWe0

In short, you create a flow that runs daily and looks for all flows in the environment created in the last 24 hours. Then, add the service account as a co-owner to each of those flows. PowerShell also offers functionality around this.

If you are looking for additional help around governance, Microsoft created a Center of Excellence package that you can install in your tenant to help with managing.

[doppers]

Hi and very grateful someone has already asked this question 😀 , I wanted to follow on from this point as we have a similar situation in my firm.

Can I please confirm  :
a) that the 3rd party developers have named account with least privilege access (quite rightly!) to build the app and flows?

b) can the developer add the service account to the app and flows to be a co-owner manually or this has to be done as suggested 

c) once developer has completed the work, we can disable the named developer account so app and flows will not break as the service account is the co-owner?

[BCLS776]

---

@doppers wrote:

Hi and very grateful someone has already asked this question 😀 , I wanted to follow on from this point as we have a similar situation in my firm.

Can I please confirm  :
a) that the 3rd party developers have named account with least privilege access (quite rightly!) to build the app and flows?

b) can the developer add the service account to the app and flows to be a co-owner manually or this has to be done as suggested 

c) once developer has completed the work, we can disable the named developer account so app and flows will not break as the service account is the co-owner?

---

To more fully answer your questions, I suggest searching on here for what firms do when citizen developers leave a company and their account gets shut off - it is a very similar situation.

Yes, you can add co-owners manually, but an automatic flow that does this for you is a great fail-safe.

I recommend having a conversation with your developers about what you intend to do with their accounts after the work is done. You want to be clear with them that you expect any functionality they build to continue working after the account is disabled. Depending on what they are doing for you, this may require more than adding co-ownership to flows/apps.

Hope that helps,

Bryan

[DS2]

Hi @doppers 
We are following this path:
1)The third-party developers get least privilege and named accounts and they only have access to the dev environment. We move the solutions either via pipelines, manually or eventually ALM Accelerator and therefore the correct account (service account for the App) gets ownership 
2) We ensure they transfer ownership of the solution in Dev before their contract is done

Does that help?