How to Prevent Makers from Deleting Solutions in Shared Environments?

(0) Share

Report

Posted on by CU27031833-0

Hi,

I’m currently working on defining a Power Platform environment strategy.

In our shared environments for small citizen development apps (standard connectors only), I’ve noticed that users with the Environment Maker role can see other makers’ solutions and also have permission to delete them. I understand this does not delete the underlying apps or flows, but they still have that capability.

I tried customizing the Environment Maker security role to restrict this, but that removed the ability for users to create apps and flows, so it’s not a viable solution.

My concern is: how should this be handled in practice? I don’t want to create many environments per department just to isolate users, as that quickly becomes complex to manage.

So my questions are:

How do you control or mitigate the risk of makers interfering with each other’s solutions in shared environments?
Is creating more environments the only real option, or are there better governance patterns?
What is the recommended approach in this scenario without breaking maker productivity?

Any practical guidance or real-world experience would be appreciated.

Categories:

Governance & administering

I have the same question (0)

All responses (4)

Answers (0)

Sort by

Suggested answer

Pstork1 69,347 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!

Probably the easiest way to handle this would be to give each developer their own developer environment. They can create their solutions there where no one else has access to delete them. If that's not possible your only real other choice is education and governance. Establish a process for removing Solutions from Shared environments and teach people not to delete solutions that they are not the Publisher for. From my testing there is no way to successfully remove the delete permission for Solutions and still have the ability to create apps and flows in Solutions.

----------------------------------------------------------------------------------
If this Post helped you, please click "Does this answer your question" and give it a like to help others in the community find the answer too!

Paul Papanek Stork, MVP
Blog: https://www.dontpapanic.com/blog

Was this reply helpful? Yes No
CU27031833-0 25 on at

Like (0)

Report
Copy link

Link copied!

Hi @Pstork1,

Thanks, that makes sense and I agree with the governance approach.

My only concern is using different publishers per user (Publisher for). From what I’ve seen, best practice is to keep a consistent publisher because it defines the prefix and follows the solution across environments. If a solution later becomes critical and moves through ALM, multiple publishers can create inconsistency or conflicts.

Have you seen this approach work long-term without issues?

Was this reply helpful? Yes No
Pstork1 69,347 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

If you want the same publisher for ALM that's fine. The advantage of multiple Publishers is that if each Dev is a Publisher then you will automatically know who to contact if the Solution needs updates or there is a problem. Publishers don't do anything in terms of security, but they do provide contact information for who created the Solution. That was the original point of the Publisher was to use it as an ISV to mark where the Solution came from. But having multiple Publishers would only create inconsistency in terms of prefix's if you try to create the same Tables or other entities in multiple solutions. Otherwise the prefix is an internal mechanism to provide uniqueness so there shouldn't be any conflicts or inconsistencies.

----------------------------------------------------------------------------------
If this Post helped you, please click "Does this answer your question" and give it a like to help others in the community find the answer too!

Paul Papanek Stork, MVP
Blog: https://www.dontpapanic.com/blog

Was this reply helpful? Yes No
Suggested answer

11manish 1,508 on at

Like (0)

Report
Copy link

Link copied!

You cannot safely restrict Environment Maker permissions to prevent solution access without breaking core functionality. The recommended approach is to use a combination of environment segmentation (not per department but per lifecycle), governance via CoE, and strict control in production environments rather than trying to enforce isolation within a single shared environment.

Was this reply helpful? Yes No