Custom Security Role | Create, Delete and Edit only OWN Tables

[KSven]

Hi lovely Community,

for my set up of tables I would like to create a security for 2 different "Admins".

Both Admins should be able to create new tables and of course to delete them as well, but only their OWN table.

In addition they should be able to add or delete some columns of their OWN tables.

Admin A cannot do something with tables of Admin B and Admin B cannot do something with tables of Admin A.

Would this be possible?

I already know I can give privelegies with Entity and Field option, but where to set up "ONLY OWN TABLES" ?

Unfortunately theres no option to use the key:

In addition I thought if Admin A has no rights for a table of Admin B, he would not be able to do something with this table, even if it looks like that:

But after my testing with two users, if a user hast Entity or Field privelegies, this user has the rights for all tables..

Any ideas?!

BR,

Sven

[jolanger · Accepted solution]

There's no ownership related to tables itself, if a user have admin or system customizer rights and can create and modify tables, they have access to all tables in the environment.

I don't know if it really helps in this use case, but you could set up two separate environments for each of the admins, and import solutions from both environments into a joint environment. Creates a bit of additional work and a proper ALM process should be in place to deal with dependencies etc, but it would restrict access for each of the admins. 

[ChrisPiasecki]

Hi @KSven,

You will need provide separate environments for each admin to do their isolated customizations. You would use Solutions to package up these customizations, export them as managed, and import them into a common environment. Solutions that are imported as managed mean the components contained cannot be customized unless the author of those components allow it via the Managed Properties for each component. 

https://docs.microsoft.com/en-us/powerapps/maker/data-platform/set-managed-properties-for-field

---
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.

[EricRegnier · Accepted solution]

Hi @KSven,

You are able to achieve this but not with privileges, but with proper solution management as @ChrisPiasecki suggested. To supplement, here is more context and steps:

Env A for Admin A

1. Admin A is system admin in env A
2. Admin A create a Table A in env A
3. Env A has a Solution A containing Table A

Env B for Admin B

1. Admin B is system admin in env B
2. Admin B create a Table B in env B
3. Env B has a Solution B containing Table B

Shared env X

1. Both Admin A and B are system admin in env X
2. Solution A and B are imported from their respective envs as managed
3. Admin A and B perform the desired changes to table A and B respectively in env X
4. Env X has a Solution X containing tables A and B sub-components that changed

Prod env P

1. Both Admin A and B are system admin in env P
2. Solution A and B are imported as managed
3. Then Solution X is imported as managed

Note: don't be worried about the number of envs, licensing are no longer by envs 🙂

Hope this all makes sense!

[KSven]

Hi Guys @jolanger / @ChrisPiasecki / @EricRegnier ,

thank you for your replys! 

@EricRegnier, I have tried to reproduce your steps:

Environments:

Env A for Admin A - Solution A

Env B for Admin B - Solution B

Shared env X - Database includes both created tables

My Questions for Pro env P:

1. If Admin A as Systemadmin in Env X would like to change Table B of Admin B he can't cause the solution B is managed by Env B and here's only Admin B Systemadmin? Or how to understand "managed" Solution?

2. If Admin A would like to create a new Table A1 (also not editable for Admin B) he need to do this in Env A or Env X?

Thank you in advance!

BR,

Sven

[ChrisPiasecki · Accepted solution]

Hi @KSven,

1. Correct, Admin A won't be able to change the table created by admin B unless the managed properties are set to Customizable = Yes. Admin B would configure these settings in Env B before exporting as managed and Importing into Env X. 
2. Admin A should use env A for creating a table that they do not want others to change.

Use env X for creating tables that you are ok with other Admins being able to change.

---
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.

[KSven]

Hi @ChrisPiasecki ,

ok great, I guess now I got the concept!

Thank you all!