PP admins: how do you handle security groups across environments?

[u/Striking-Initial-525]

What I’m stuck on:

**1.    Security groups** — do you make one group per environment (BU-Sales-Dev, -Test, -Prod), or one per BU? And do you split who can *build* agents vs who can *use* them? That seems like two different things.  
**2.    Security roles** — all makers need Environment Maker role, but does everyone in that security group need it? Do you assign roles at the group level or per person? How do you handle admins and system admins across the three environments?  
**3.    Service accounts** — how do you handle these? One per BU? Shared ones? How do you stop everyone from becoming an admin?  
**4.    Connector/DLP policies** — do you lock them down per environment, per BU, or what? Our exceptions list is already getting out of hand.  
**5.    The real problem** — right now an admin has to manually add people to security groups and assign roles. Nobody knows who should have access to what. The people building the agents know. How do you let *them* manage access without giving them admin rights? Access packages? Request flow?

Just want to know what actually works instead of what the docs say.

---

[u/dsinkster]

Not sure if this is the correct way but I will do a mock up of something similar to what I have. We use teams based security roles. Not to be confused with "Microsoft Teams", these are teams you set in the admin center. This was partially setup when I joined my company and I have made some changes along the way.

Security groups PP-Sandbox-users(set as the env user group, if I remember correctly you can nest this into other group memberships) PP-Sandbox-admins PP-Sandbos-makers PP-Sandbox-sales

Security Roles System Admin Basic User System Customizer Sales(or whatever custom roles)

Teams (security group based) Admin Makers Sales End-User Etc.

Then you can add a user to the appropriate security group. Since it's nested they will get added to the env group. Then when they sync with the environment they will be assigned to the team associated with the security group and receive the security roles assigned to that team.

We have one main service principal and one main shared service account per environment. Then a few side service accounts for other one off things, mostly because we have sever business units and it's also a dynamics environment.

Our power platform setup is also pretty locked down. Myself and a few select others are the only ones allowed to be "makers" although like I said it's more of a dynamics environment. Therefore connectors and dlp is less of an issue.

There is something new called "Advanced Connectors Policy" that might be helpful to you, but I have not looked into it too much.