Power Platform Environments

I had an interesting converstation with my Architect recently about Power Platform environments, 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

#	Role Name
1	Agent 365 Tools Role
2	AIB Roles
3	AIB SML Roles
4	ApolloServiceRole
5	App Deployment Orchestration Role
6	App Opener
7	Approvals Administrator
8	Approvals User
9	Async ingestion
10	Basic User
11	BizQAApp
12	Bot Author
13	Bot Contributor
14	Bot Transcript Viewer
15	Bulk Archival Role
16	BusinessApplicationPlatformRole
17	Cards Basic Role
18	Cards Role
19	CCI admin
20	ContextualAIS2SRole
21	Data Sync Framework Role
22	Data Sync Service Role
23	Dataflow Maker
24	DataLakeFolderEntityContributor
25	DataLakeWorkspaceAppAccess
26	DataProcessingConfigTableAppAccess
27	Dataverse as a Cluster App Role
28	Dataverse Search Role
29	Deflection Service Role
30	Delegate
31	Delegated Mailbox Approver
32	Desktop Flow Machine Configuration Admin
33	Desktop Flows AI Application User
34	Desktop Flows Machine Application User
35	Desktop Flows Machine Owner
36	Desktop Flows Machine User
37	Desktop Flows Machine User Can Share
38	Desktop Flows Module Developer
39	Desktop Flows Runtime Application User
40	EAC App Access
41	EAC Reader App Access
42	Environment Maker
43	Export Customizations (Solution Checker)
44	Fabric AI Skill Role
45	Federated Knowledge Role
46	FileStoreService App Access
47	Flow-CDS Native Connector Role
48	Flow-RP Role
49	Global Active Metrics Monitoring Alerting Custom Role
50	Global Discovery Service Role
51	Help Page Author
52	Help Page Consumer
53	Insights Apps Platform Role
54	IntegratedSearchApp
55	Knowledge Manager
56	Knowledge Quality Service
57	Knowledge Quality Service Role
58	Microsoft Copilot Administrator
59	Microsoft Copilot User
60	Non-Relational Data App Access
61	Office Collaborator
62	Omnichannel CDS Flush Role
63	Portal Application User
64	Portal RP Service Role
65	Power Apps Checker Service Role
66	Power Automate AI Flows Application User
67	Power Automate Operator
68	Power BI Embedded App Access
69	Power BI workspace admin
70	Power BI workspace contributor
71	Power BI workspace viewer
72	Power Platform Data Analytics Role
73	Power Platform Dataflows Service Role
74	Power Policy App User Role
75	PowerAppsRPRole
76	PowerPlatformInsightsRole
77	Process Mining Application
78	Process Mining User
79	Project Background Services App Role
80	Purview Label Role
81	Report Service Role
82	RPE Role
83	Service Deleter
84	Service Reader
85	Service Writer
86	Solution Checker
87	SuggestedActionS2SRole
88	Support User
89	SupportUserCustomAPI Role
90	Sustainability all - full access Role
91	Sustainability all - ingest - full access Role
92	Sustainability BusinessUnit - full access Role
93	Sustainability BusinessUnit - ingest - full access Role
94	Synapse Link Service Access
95	Sync Permissions
96	System Administrator
97	System Customizer
98	Teams Chat Sync App Access
99	Tour Author
100	Tour Consumer

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 is not fun. Everything is silo'd 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 democracising 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.