Let's Talk About Power Platform Environments

I had an interesting conversation with my Architect recently about Power Platform environments (aren't all chats with Architects always the most fun 😎), we have the most fun chats lol. And it made me think I thought about how they should probably change, and what the future holds.

There are 3 things that I want to talk about:

1. Quick Fixes
2. Big Fixes
3. The Future

1. Quick Fixes

The trusty Power Platform environments hasn't changed much over the years. Yes we have had managed environments and developer environments. But they are only skin deep changes, deep down nothing has changed. And that makes sense, as its the foundation of the platform so we can't go around making breaking changes.

But I think there are still a few easy win changes.

Well first lets go back to that elephant in the room, Dynamics. As the Power Platform is built on Dynamics, that means every environment is setup like a Dynamics instance.

Security Roles

There are a 100 security roles added to each new environment, now I don't about you but I have probable used less then 10, check out this list, how many do you even know, can you tell me what even half do?

Imagine if we only had Power Platform specific roles, maybe:

• Environment Maker
• System Administrator
• System Customizer

We then have an option to add roles like Approvals, Copilot Studio and Power Automate Desktop. All of the system ones for spn's could be abstracted away. Finally I would make basic user on by default, so if you access the environment then you are given the role. And any that are removed with no way to add could be documented so that admins can create them themselves if needed (or our friend Copilot 😎.

System Customizer

There is also the problem with the system customizer role. Its Dynamics day role was to allow the maker to create custom tables. Without it if you create a custom table you can't add data to it without a custom security role (so you need to make the table, then make the role, then use the table). The idea was sound, as it removed the environment settings but allowed the developer full access to the data in the non-prod environment. But as the Power Platform grew and became solution aware the plan broke.

Because the platform is built on the platform i.e. flows are stored in the same way as custom data, we have a big issue with our security roles.

• You want to create Dataverse tables - System Customizer/custom role
• You want to add data to a table without a custom role - System Customizer
• You want to create custom AI builder model - System Customizer
• You want to create a security role - System Administrator

Thats right to do any of the above development I need the permission to see all Dataverse tables, including system tables like flows. And if you want to give someone that secuirty role, well only admins can, because you could easily give yourself any role.

There needs to be a new role that is purely scoped to custom tables created by the maker. That way if you create a table you can add data etc, but no one else can until they are given permission.

Common Data Model tables

We also have the Common Data Model tables, as the environment owner I should decide if I want a Accounts table, don't waste my expensive Dataverse storage with unused/misused tables, and clutter it with tables I will never use.

Not only would you save all that Dataverse capacity you get the added benefits of:

• Simpler to administor
• Less vector of attack (unecessary roles and consitent database structure is a hackers Christmas)

The simple approach would be to have the tables in a solution you can download/add.

As this is a quick fix section, the easy update would be to enable admins to delete the tables, so I may be forced to include on setup but I can at least run a script/flow post setup to remove them

2. Big Fixes

In a nutshell an environment is kind of a container.

Containers are lightweight, portable software packages that bundle an application's code with everything it needs to run (libraries, dependencies, settings) into a single, isolated unit, allowing it to run consistently and reliably anywhere.

If you think of things like Dataverse tables, api's, model driven apps, as libraries, dependencies, settings, then it kind of makes sense.

In the Microsoft world you might even think of them as a Resource Group (I suspect under the hood they are). But a resource group is meant to act as a lifecycle boundary: everything in it is created, updated and deleted together. Guess what has a lifecycle boundary in the Power Platform, that's right a Solution.

So really a solution is a resource group, but its not treated like that. Because Resources groups also come with scope permissions to the Resource Group and its contents, Solutions do not have that, there is no permission to see a Solution, just its contents. A Solution is more like a filtered view then a folder.

And I think that contradiction has made a mess. And its because of the Dynamics, which treats solutions like components and the environment the container. If you see it through the eyes of Dynamics it makes sense, but through the eyes of the Power Platform it doesnt.

I think there needs to be a refocus, with the environments tending more to Power Platform needs.

We need to treat solutions more like the container. They need to have security roles scoped to them. So as an example a developer with a Solution Customizer role could:

• See everything in the solution
• Create custom tables and add data to them within the solution
• Edit all flows/apps within the solution

But they couldn't:

• Delete the solution
• Create security roles at the environment level
• Edit solution details

That would be limited to the Solution Administrator or other role.

This would bring the power platform in line with PoLP (Principle of Least Privilege), as someone who simply wants to create a custom table and security profile should not need permission to change the environment settings and view/edit all other developers work.

The other big issue, which Microsoft is trying to fix is hierarchy. Each environment is a totally separate entity. This is ok when you work within the environment, but what about when you work above. As a environment admin dealing with environments its not fun. Everything is siloed away, and getting a rolled up global view is only possible by a series of loops and copying of data.

The new Inventory setup in the PPAC is trying to solve this problem, and doing well. But under the hood it seems to be just doing the loops and copying for us, not fixing the underlying issue. It also is:

-Limited to Global Admins (PolP alert, though RBAC is planned)
-Limts data to PPAC

The environments should be structured in a hierarchy, with all platform data in one source. Then each environment role a given permissions to those records. Why have a hundred Security role tables when we could have one that is filtered to each environment.

Although that sounds like more work for the CoE, who now cant outsource environment administration so easily, it doesn't stop this, and it gives them greater visibility and control (and don't forget, with a Solution Customizer role you shouldn't need admins purely to create security roles).

3. The Future

So that's how I would fix enviroments, strip them down to focus on the Power Platform, and create lower-level granular security roles at the solution level.

But what about the future, well that's where I think the environment update becomes more important. The Power Platform is growing beyond Low-Code, for a long time the platform was simply to enable the low-code tools. But with the advent of AI, and the democratising of Pro-Code we are fast approaching a would where the platform becomes the value.

Code Apps prove this, if you think about it, I can now use GitHub Copilot to create feature which Pro-Code apps/sites, but that is only ski deep. Things like security, Auth, life cycle, deploying, load balancing, etc are all things that AI can maybe do, but not easily. Enter the Power Platform, now my AI generated apps are secure, have built in auth, deployments, roles, life cycle, everything that you would worry about, How cool is that, you have the walled garden that you can unleash AI in with a lot less risk.

For a while its felt like its hard to get improvements in the Power Platform unless its Copilot/AI related, so for a while I doubted updates to the environments would ever happen. But now with the ability to use the platform for AI generated code instead of Low-Code, I think it might get the support now, come on Micrsooft, lets get environments fixed.

 
😎 Subscribe to David Wyatt