Environment - System Administrator role best practices

[calamityjen]

Hi,

I could do with some advice around Power Platform environment roles.

I don't usually allow the system administrator role to be given on an environment, as it opens up a lot of settings that I'd rather not be touched (e.g. turning on PCF components / multi-geo settings.  Both of which need approval first).

The problem is that more people are requesting this role, so they can do things that that system customizer role doesn't allow, such as creating custom security roles.

My questions are..

* Are there any best practices around the allocation of the system admin role on an environment? The evironmet strategy seems to say to only allow Environment Maker / Basic User.

* How can I allow users to create security roles, but not poke with any of the other environment settings?

[Velegandla]

@calamityjen 

* Are there any best practices around the allocation of the system admin role on an environment? The evironmet strategy seems to say to only allow Environment Maker / Basic User.

* How can I allow users to create security roles, but not poke with any of the other environment settings?

• You need to ask who is developing the solutions and where. 
• If it is business users or Pro devs, all the development needs to be done in development environment (s).
• Depends on the use case you can multiple development environments so you can manage the access levels. 
• Also, less risk because there is no live data. 
• Once application is developed and tested, you can use pipelines(Power Platform pipelines or Azure devops or manual approach) to deploy the solution (managed) in production environment. 
• Production environment will have only one admin. 

====================================================

If I have answered your question, please mark your post as Solved.
If you like my response, please give it a Thumbs Up.

https://www.linkedin.com/in/devendravelegandla/ 

[calamityjen]

Thank you - though regardless of experience, I don't want anyone except the D365/Power Platform admins from making changes to those environment settings.  It seems there's no way around that though.

Do other people here allow the system admin role to be used in an environment?

[chapmangs]

Have you made any progress on this topic?  We have been seeking a 'best practice' for the same issue and it seems there is not a solution. There does not seem to be a means to create a customized Security Role that disables the ability to change Environment settings but allows the ability to add users to the environment or create security roles for dataverse. We considered utilizing 'System Customizer' alone for 'Environment Admins' and using AAD groups to provide Maker and Approver access to the Environment that were managed by the 'Environment Admins'. This requires a significant amount of work, so currently considering reactive methods with Alerts from the Environment based Audit Logs.

[Velegandla]

@chapmangs 

It's always work vs reward. 

If you are using the development envs for developing solutions and promoting to Prod, then env settings are not a major issue. 

In prod only IT will act as Admins.

Of course, it depends on the organization's maturity. Do you allow people to manage their own by providing training, etc.?

If you do not have development environments, System Customizer is the best option to limit people changing settings. 

But giving a System Customizer role in the Prod environment doesn't help, and it creates more issues even with the reactive method. They can create solutions, tables, etc, in Prod env.

The key thing is to come up with an environmental strategy that is suitable for the needs. This could potentially reduce the risks later stages.

====================================================

If I have answered your question, please mark your post as Solved.
If you like my response, please give it a Thumbs Up.

https://www.linkedin.com/in/devendravelegandla/ 

[calamityjen]

Hi - not yet, still mulling the problem over!

[calamityjen]

Well, the environment settings in some case can introduce risk - settings such as PCF components.  With the potential security risk around those, we have a process for approval before the setting is turned on / off after deployment.  So, allowing users to just turn on and off settings is not an option.

I'm going to try to create a hybrid role - just need to find a spare moment 😁

[Velegandla]

@calamityjen 

I understand what you are saying about risk with PCF controls. 

Here is how I manage it. 

I will publish the guidelines on how people need to use PCF and what would be approval process. 

I will then let people use the PCF controls in development environments. 

I will have a starter kit that gives me insights into who is installing the PCF components. 

I ask users for more information on what they are doing and why they are doing it—this is mostly a review process. 

They will not get this feature enabled in production before IT approval.

I don't know how many environments you have. This would help minimize the management of all environments by yourself.

Also, I would see fewer people using PCF controls. Not all requirements need PCF controls. 

I am keen to hear why you wanted to manage all environments rather than let others own them. 

In the future, if you want to enable environment routing, etc., you need to let people have their environments. 

I suggest revisiting the environment's strategy and planning for upcoming features that could increase adoption and improve governance. 

====================================================

If I have answered your question, please mark your post as Solved.
If you like my response, please give it a Thumbs Up.

https://www.linkedin.com/in/devendravelegandla/ 

[calamityjen]

Hi Velegandla,

Interesting, and possibly something to think about.  

PCF was one example.  Anything around moving data between geographies ('Enable cross-geo support for hosted machines') also needs approval, and also the auditing settings (because of the space used) and the ability to convert a Sandbox to a Production environment are other setting that we'd rather not be touched. 

Anything to do with AI might need to be checked / approved too.

We have many environments 🙂

[Velegandla]

@calamityjen 

I would recommend starting with a proactive and reactive approach. 

Create simple guidelines for your admins. 

This could be 30 30-minute training videos or Individual KB articles.

They need to follow the process and if they do not then they will lose the system admin access. 

Use the starter kit and other monitoring tools to review the settings, capacity etc.  

You also need to start exploring managed environments if you have too many environments to manage.

It doesn't do everything at this time, but you can give feedback to the product team.

Join their private preview program and talk to the product team. 

https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-overview 

====================================================

If I have answered your question, please mark your post as Solved.
If you like my response, please give it a Thumbs Up.

https://www.linkedin.com/in/devendravelegandla/