How Security Role Privileges are Inherited from Team to User

By | November 14, 2014

If there are multiple users, business units and teams in any CRM system, then it is not necessary that every user has maximum rights/ privileges/ roles. There are situations where a minimum permission user should be able to create an entity record for which individually it does not have rights but his/ her team has those rights. So we think that should work and user should be able to create records, say suppose quote record. But there is more to this concept which we have explained in this blog.

Considerations and terminologies used in following use case as an example:

Team A – Team who has permission and its team member user does not have any permission

User A – One of the team member that comes under Team A which does not have any permission

Parent BU – this is a parent business unit and Team A comes under this BU

Child BU – this is child of BU Parent and User A comes under this BU

User role – no level of read, write or create privilege on quote entity and this security role is assigned to User A

Team role – USER level read, write and create privilege on quote entity and this security role is assigned to Team A

In this case, the quote record cannot be created with User A as the owner but he/ she can create quote record after setting Team A as the owner, here created by/ modified by will be User A.

If Team role is given parent child BU level permissions, then too it does not work because User A falls in Parent BU whereas Team A falls in its Child BU.

So when organization level read, write and create privilege on quote are given to team role, then user A can create and be owner of quote record. Note here User A still does *not* have any level of privilege on quote individually as per his/ her personal security role.

Now consider the setup where only change is been made is that Business Unit of Team A is changed to Parent BU from Child BU, so both Team A and User A are under same Business Unit i.e. Parent BU.

In this case, if you provide Business Unit level read, write and create privilege of quote to Team role, then also User A can create quote record under his/ her own login and owner of that quote record will also be User A.

Hence, if you have a role which provides create, read write privilege at a User level for some entity, and this role is only assigned to a Team, then any user in that Team can create records of this type, but only if they make the Team as the Owner before they save the record. If they try to save the record with themselves as the owner, the security model does not allow this.

Here one might think, I am the member of this Team, so team’s role should apply to me and make me act like a team and allow me to create these records, but the role has user level permission by which it means it is applicable only for “you”, i.e. the Team itself, not you, yourself.”

Conclusion:

While setting up roles for team with the perspective of getting them inherited to its team members, the level of privilege on respective action is important depending on situation if that should be allowed to same business unit team members or any of the team members, but in any case user level privileges will not work in team’s role.