System Customizer Security role concern and solutions

[ShaneMeisnerTH]

After researching the error "Publishing all customizations failed."  when a user tried to click the "Publish" option when exporting their solution, I found that giving them "System Customizer" role resolved it.. 

The issue is, that security role is too powerful for regular users.
I have a test account that I gave that security role to and found that not only could it not publish solutions without the errors. But it could also edit existing solutions in the environment and make changes to unmanaged items.

Any ideas how I could give regular users rights to click the "Publish" option when exporting their solutions without generating the error, while also preventing them from editing existing solutions?

[ChrisPiasecki]

Hi @ShaneMeisnerTH,

You can't selectively control whose unmanaged components solutions one can edit because there is no ownership assigned to most metadata (e.g. Tables).

The recommended approach is to have a separate development environment for customizing the specific solution(s) with only granting access to the makers who should be working on that solution.

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.

[ShaneMeisnerTH]

 @ChrisPiasecki  .. Thanks for replying.. Through testing we did find that those with "Environment maker" security role can only see and edit their own solutions and they can export and import into different environments with that same role.

The issue is if, during exporting, they click the Publish button, it generates an error that they don't have the right permissions. 

Trying to find the appropriate setting that we could create a Custom security role that would give all the rights of Environment Maker, and enough of the System customizer role to publish, without the ability to edit other Solutions.

[ChrisPiasecki]

Hi @ShaneMeisnerTH,

What is the exact error you are seeing? Note that Environment Maker will be able to modify their own apps, flows, connections, and gateways, and share these resources.

Environment makers do not have privileges to create/modify Dataverse specific components such as tables, views, etc.

Does your solution contain any Dataverse specific components like a table? If so, you'll need to remove those components from your solution, or you'll need the system Customizer role.

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.

[ShaneMeisnerTH]

The error they get is :

Publishing all customizations failed. SecLib::CheckPrivilege failed. User: , PrivilegeName: prvWriteEntity, PrivilegeId: , Required Depth: Basic, BusinessUnitId: , MetadataCache Privileges Count: 4126, User Privileges Count: 1133

We've tested just creating a flow in a new solution and exporting that Solution and get the same error when they click the "Publish" Icon:

As I mentioned, all results I found to resolve that error were to grant them "System Customizer" or "System Administrator" Security roles, both have way too much power for "Citizen Developers" ..

This is why I think a Customized Security role would work..
If I could just figure out what setting would allow them to Publish, without the ability to Edit existing Solutions that they didn't create.. 

[jukka-niiranen · Accepted solution]

I tested this based on the error messages that "Publish All" gives when using Environment Maker role. In my simple demo environment with a very basic solution containing one custom table and a couple of apps, the write privileges that I had to add were these 4: entity, field, relationship, view.

Will this work for everyone and everywhere? Not so sure. Obviously this isn't quite the way Microsoft has intended the security model to work. As Chris mentioned earlier, there isn't an ownership concept on the Dataverse metadata level - meaning it's all organization owned and not user owned.

[ChrisPiasecki]

Hi @ShaneMeisnerTH,

The privilege lacking is write access to the Entity table, which is expected as I mentioned the Environment Maker doesn't have the privileges on those Dataverse metadata tables (table, view, field, relationship, etc.).

Creating a custom security role won't help you here because the permission scope can only be set to organization or none for those tables, which means you can either modify ALL of the metadata types or none at all. They would be able to modify the metadata created by others, which is not the granular access you're looking for. When you publish, you're effectively making changes (write) on the different components in the solution visible to everyone. 

Separate environments is the simplest way to prevent others from messing with other people's solutions, and is a common pattern.

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.

[ShaneMeisnerTH]

@jukka-niiranen and @ChrisPiasecki 
Thanks for your help.
I made a copy of the Existing Environment Maker Security role and made the changes Jukka mentioned.

I then removed Environment Maker role from my test account and added the Customized role.

My test user now was able to create a new Solution, add a App/Flow and during export I was able to publish with no errors!

I tried to open other solutions in that environment that it didn't create and I get errors, like I did with just the Environment Maker role:

I'll to do some more testing, but for now it looks like what jukka posted works as we need.

Last thing I wanted to do was manually export all solutions 18,000+ user might create.. and Also didn't want to create hundreds of different environments just to make sure people didn't edit solutions they shouldn't.

[ChrisPiasecki]

Hi @ShaneMeisnerTH,

Just be aware that it doesn't stop someone from modifying those components directly outside the solution in the maker portal (via the Dataverse > Tables tab), or simply adding the components to their own solution, modifying them, and exporting them. Preventing the users from modying the solution container of others and exporting solution is a moot point when those other workarounds exist.

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.

[ShaneMeisnerTH]

Thanks @ChrisPiasecki  .. Right now our concern is allowing Citizen Developers the ability to export their Solution form the Power App interface and importing it into the correct environment, without being able to edit solutions they didn't create.
I started n July to help them cleanup their Power Platform environment as they have 400+ Apps, and 1500+ Flows all in the Default Environment.
There are currently only 6 Premium Licensed users, with 4 of those being our team( 2 Admins and 2 Service Accounts). All the Citizen developers we've worked with either use SharePoint or SQL for data and we are not promoting Dataverse at this time due to the extra cost of licensing.
If in the future we decide to start using Dataverse more, then we will have to revisit this "fix". But for now this will do the trick.