Best practice: Assigning users to master/parent roles ?

[Former Member]

Hello everyone,

As a rule here in the NAFTA region, we create master/parent security roles with * access to all org levels.  But we do not assign users to master/parent security roles.  Instead we create a new derived role with * access to all org levels and assign users to this derived role.

We are getting push back from other regions with this concept and they want to assign users to the master role for * access.  They are demanding proof or a best practice document stating why users should not be assigned to master/parent roles.

I am curious of others opinion on this and if there are best practices out there.

Bryan

[Former Member]

Best practice is actually to avoid the pestilence of derived roles... 🙂

There are several discussions about this already if you use the search.

However, to minimize your damages you can consider that you will want to test the roles with org.level neutrality before you introduce the org.level restriction.

So it is a wise idea to leave the parent role without any org.levels maintained (even although some org.levels such as "account type" and "user group" are irritatingly org-levels...). Then have the first child of the empty parent as the * org.level role for those fields which really are org.levels. Or even a dedicated test child role.

Advantage is that you "develop" on your parent role only and from the "test" role with org.level neutrality you can adjust it to the changes of the parent without having to touch any of the real ones.

Hidden advantage is also that you will also be tempted to start changing roles in production anyway because you have so many of the little things and transporting them is so painfull, so in these cases you can at least still make changes and see the effect and test it before adjusting the childs or generating their profiles outside of the development client.

As mentioned at the beginning, I can only recommend avoiding derived roles and the restraints of org.levels.

Cheers,

Julius

[Former Member]

Hi,

I would partially agree with what Julius said. If there is business requirement to restrict on Org levels, then the best approach is to use derived role concept instead of going with the unconventional, so called "Enabler Role" concept!

However, I agree it is advisable to maintain org level values for the Master Roles as "Dummy" and maintain specific values in the child roles which should be assigned to users.

There is no business level justification as to why Master roles should not be assigned to users, but from Security practices perspective, Master roles should be kept aloof just for central role maintenace purpose and child roles should be for org level restriction and user assignment.

Thanks,

Deb