Most of the documentation out there for Power Platform is a bit vague when it gets to when to apply what role. Here’s what the key roles are in Power Platform and where to use them.
The Key Roles
The first three roles below apply to the environment-level only. This is a key distinction, because while some people might assume that making someone a system administrator in a platform will make them have an credibly high level of power, in Power Platform that is limited to the specific environment in which it is applied. It’s like… being king of a castle, but the castle could be a small shack in the middle of nowhere. It’s not king of the country, or even state, if that makes sense. It’s very common to let developers have full admin permissions on their own personal environments, for instance.
The exception to this rule is the “default” environment, which is kind of the catch-all for new user content as well as the default for a lot of apps like premium Planner for the Web. This one you don’t want to be handing out the keys to freely.
Basic User
Basic users can interact with items that have been shared with them and whose base tables they have permission to interact with via security role. Having a basic user role on an environment does NOT automatically grant you access to interact with anything or read any data there. Apps still need to be shared with the user, and other roles need to be granted to the specific tables they need to access.
Environment Maker
This means a user can make things in the environment. NOT make environments. The phrasing is a bit confusing. By “things”, I mean apps and flows – NOT Dataverse tables, which is often the complication when you get to trying to make solutions in Dataverse. What typically happens when you request access to an environment is you’ll be granted maker, and be unable to create your custom tables, then spend the next 3 months trying to convince someone that you also need system customizer.
All users have maker access to the default environment by… default.
People who are making canvas apps and flows that use SharePoint as a data source will be able to squeak by with “environment maker” role in most cases. People who are making apps that reference Dataverse as a source will also need “system customizer” if their solution involves creating or modifying tables (which it almost always does).
Can you import solutions with just environment maker access? Sure, if your solution doesn’t attempt to create or modify tables, columns, or other things that maker role doesn’t grant.
System Customizer
This role CAN create and modify Dataverse tables. It does NOT have access to all data in all tables, only those for which it has a security role on in the environment or for tables it creates. It cannot add users to the environment or apply security roles to users (but it can create roles for the tables it creates!).
Environment Administrator
Environment administrators can add users to the environment, grant security roles to users, and do everything that the system customizer and maker can. It can also see and modify all data in all tables in that particular Dataverse environment. Again, this sounds like a lofty permission level, but if you’re creating a new environment for a small group, the reach is quite low.
This is why a big part of security in Power Platform boils down to environment management – more environments is not a bad thing; it limits scope of individuals and makes people less likely to break each other’s (or their own) stuff.
If you want your Power Platform developer to be able to manage the access to the things they create, you need to either create a custom role that lets them apply security roles and invite users, or give them environment administrator of the environments they are creating in.
Power Platform Administrator (or … gasp, Global Administrator)
The Power Platform administrator can access the Power Platform admin center and do virtually anything with any environment. Ditto on the global admin, obviously global administrator access should be very restricted.
Conclusion
Power Platform security roles are set up in such a way that it can be a bit confusing to figure out who needs access to what and how to structure things. To both maintain the least-privilege access while also making sure your developers are able to function, it’s a good idea to create specific environments for departments, projects, or use cases. This lets you grant high level of access to developers while avoiding crossing wires.