Admin role best practices

jMarshal
Mega Sage
Mega Sage

ACs have "admin override" properties that allow platform admins to get table/field/app access without needing to explicitly have a role (the role) on which the AC is built/evaluated...this is good.

However, there are other actions/functions that could depend on role beyond access control, which are not achieved without the platform admins actually having a specified role.

For example, if a custom app has a custom role that is required for a particular UI Action to be available to a user, a platform admin (role=admin) wouldn't have that role inherently and wouldn't be able to see/use that UI Action when troubleshooting/developing/etc...

...when it comes to platform governance and best practice, I'm looking to suggest that whenever a developer creates a role, that role is always added to "admin" also.

I am not looking to automate this, just looking to establish the practice in our organization...and if it is successful, perhaps automation is in our future.

My question is - which practice is better/best for this:

> have the developers embed the custom role in "admin".
> have the developers manually add the role to the group to which the admins belong.
> have the developers manually add the role to the specific admins who need it.

Does anyone already have an established practice related to maintaining the roles for platform admins, that would provide some insight for me, as we start to do this in our organization?

Thanks in advance!!

1 ACCEPTED SOLUTION

Tony Chatfield1
Kilo Patron

Hi, context of the role\use of the role is the most important factor here.

An admin user may have full access to data via ACL (for admin support purposes).
But if the admin user is not fulfilling the process of the role, then they would have no need for the exact role as they are not delivering it's functionality - unless they are debugging\fault finding in a development instance in which case they would add the role to manually (in subprod) their account for testing.

 

For role inheritance, I consider best practice to be role assignment via group inheritance.
IE the group defines the purpose\use case and the roles assigned to the group deliver the functionality required for the purpose; meaning even the admin role would be provided via an 'admin' group and I would add any new role\functionality to group(s), so that role assignment\removal was consistent across the platform.

View solution in original post

2 REPLIES 2

Tony Chatfield1
Kilo Patron

Hi, context of the role\use of the role is the most important factor here.

An admin user may have full access to data via ACL (for admin support purposes).
But if the admin user is not fulfilling the process of the role, then they would have no need for the exact role as they are not delivering it's functionality - unless they are debugging\fault finding in a development instance in which case they would add the role to manually (in subprod) their account for testing.

 

For role inheritance, I consider best practice to be role assignment via group inheritance.
IE the group defines the purpose\use case and the roles assigned to the group deliver the functionality required for the purpose; meaning even the admin role would be provided via an 'admin' group and I would add any new role\functionality to group(s), so that role assignment\removal was consistent across the platform.

Thank you for your reply @Tony Chatfield1 - that kind of insight is exactly what I was hoping for!