Connecting permission sets to User Groups

Unless something changed, permissions are not actually assigned to User Groups, they are only assigned to Users. It can get confusing because you can add Users to User Groups, then grant a permission set to that User Group so it looks like you are granting to the User Group, but in reality it is granting the permission set to each User in the User Group at that time.

Similarly, if you grant a permission set to a User Group (which will grant it to all Users who are in the User Group at that time) and then add a new User to that User Group, the new User you add will NOT automatically get any of the permission sets that were granted to the User Group in the past.

To achieve what I believe you are trying to do, I would create End User type Permission Sets based on the your idea of groups (e.g. Sales) and then assign that End User permission set to the relevant users.  This End User-type permission set could then include all other permissions you want to give to the relevant users as multiple Functional-type permission sets.  This way when a user moves in/out of  e.g. Sales then all you need to do is grant/revoke that one End User permission set to/from the user.

User Groups are a great way to breakdown users into buckets and are helpful for assigning permissions to groups of users, but just know that these buckets themselves are not much more than metadata tags attached to individual users for security purposes.

HTH,

Nick

Thanks for your feedback Nick! 
However I think maybe things have changed? 

To me it looks like an improvement on the user groups that you can assign permission sets and then indirect grant is done both to current and future users.

From what I understand, now by connecting the permission set to the user group, you do “kind of grant it”  to the user group and NOT to all the users currently connected (but those users will get the permission set INDIRECLY granted). Any user you add to the user group at a later point ALSO get the permission set indirectly granted. This means you can totally change a users permissions, only by removing the user from one user group and add it into a different user group instead.

But please correct me on this if I have totally misunderstood (which is why I posted a discussion on it to be sure).

If you remove the user from the user group he/she no longer have access, which is great and correct. BUT, if I happen to remove the User Group then all the users that were connected, loose their indirecly granted access. I would have understood the possibility to remove the user group better, if the functionallity were to grant the permission set (Direct) to all users currently connected to the user group, but since it is only granting  indirect access through the user group, then it should no longer be possible to remove the group while it still have users connected.

I think also because User Groups can be mapped to the configured contexts it is not good that they can be removed without first disconnecting the users. Currently it comes up with a question if you are sure you want to delete the group, but it still seems risky. I believe it would be better to have to disconnect the users, and maybe also permission sets, first? (maybe with a “disconnect all users” option?)

Again, we can configure and/or remove delete possibilities on user groups, but we still wanted to check on Community if there are any views on the matter, and what is the intended as buildt use of the User Group/Permission set connection.

Example: My test user is connected to a User Group that gives access to a permission set. This will show in the User form under USER PERMISSIONS as an Indirect grant. If moving to “User Permissions” in the record selector, here you will get “No Data Found” for Direct grants, but you will find the permission set under Group Grants and All Grants. (But all gone if you remove the user group accidentally).

You are correct on how it works, this isn’t a “click the button will grant the perm to the user”, it is in fact granted to the GROUP, and therefore acts as an indirect grant to users.

I’ve just tested this myself, and I can indeed log in with a user that purely and only has group grants rather than any direct grants, where the user was added in the group AFTER the perms were granted to the group, and I can log in and do whatever the group permissions are.

Fairly easy to see that too based on the view and entities involved

The fact it doesn’t do any cascade check on deletion to see if any members exist is indeed probably an oversight and should probably be reported to IFS as a bug to get R&D to implement that check.

This is good news

This is good validation (thanks!) and appears to be a good functionality addition that was presumably implemented with IFS Cloud; should be very helpful as a feature although functionality-wise it doesn’t really appear to much different than having a top-level ‘group’ permission set that could be assigned to a group of users, right?  Or am I missing something?

In one scenario you add the Users to a User Group and the User Group has permissions assigned to it, and in the other scenario you grant the top-level ‘group’ permission set to the Users and that top-level permission set gets permissions assigned to it...  

You’re right on the functionality aspect, but there’s two benefits that I get from it.

1. If a certain type of role is made of multiple permission sets (rather than a top level perm set like you said), onboarding is easier as you just assign that new employee to the group
    
2. In organizations (such as mine) where access to create and modify permission sets is tightly controlled by a Governance Body. The IT team onboards new employees, but we do not want regular IT staff to be able to assign themselves permission sets with a very high privilege level, nor do we want them to be able to modify permission sets or be able to grant themselves or others “super administrator-type” permissions as there are risks involved such as breaches of segregation of duty.
   
   What we do is that regular IT staff gets access to user groups and can assign users to user groups as required for any onboarding/offboarding activity, but they do not have privileges to assign permission sets to users as direct grants, meaning that they can only grant users to groups and therefore to agreed permissions that the governance body has decided.
   
   In short, only I and my direct deputies can assign direct grants to users, while the regular IT organization can only grant users to groups made of predefined permission sets based on requirements agreed upon with the governance body

HAFINGMUN wrote:

Thanks for your feedback Nick! 
However I think maybe things have changed? 

 

To me it looks like an improvement on the user groups that you can assign permission sets and then indirect grant is done both to current and future users.

From what I understand, now by connecting the permission set to the user group, you do “kind of grant it”  to the user group and NOT to all the users currently connected (but those users will get the permission set INDIRECLY granted). Any user you add to the user group at a later point ALSO get the permission set indirectly granted. This means you can totally change a users permissions, only by removing the user from one user group and add it into a different user group instead.

But please correct me on this if I have totally misunderstood (which is why I posted a discussion on it to be sure).

If you remove the user from the user group he/she no longer have access, which is great and correct. BUT, if I happen to remove the User Group then all the users that were connected, loose their indirecly granted access. I would have understood the possibility to remove the user group better, if the functionallity were to grant the permission set (Direct) to all users currently connected to the user group, but since it is only granting  indirect access through the user group, then it should no longer be possible to remove the group while it still have users connected.

I think also because User Groups can be mapped to the configured contexts it is not good that they can be removed without first disconnecting the users. Currently it comes up with a question if you are sure you want to delete the group, but it still seems risky. I believe it would be better to have to disconnect the users, and maybe also permission sets, first? (maybe with a “disconnect all users” option?)

Again, we can configure and/or remove delete possibilities on user groups, but we still wanted to check on Community if there are any views on the matter, and what is the intended as buildt use of the User Group/Permission set connection.

Example: My test user is connected to a User Group that gives access to a permission set. This will show in the User form under USER PERMISSIONS as an Indirect grant. If moving to “User Permissions” in the record selector, here you will get “No Data Found” for Direct grants, but you will find the permission set under Group Grants and All Grants. (But all gone if you remove the user group accidentally).

 

 

Thanks for clarifying.  This is a new functionality I wasn’t aware of (I only have limited IFS Cloud experience so far).

That said, if the functionality you described is what you want, and the User Group approach appears to be deficient/risky for this, then you could instead use the older approach I described - having a ‘group’ level Permission Set which you assign to users instead of assigning security to an actual User Group.  The group-type permission set that gets assigned to users would have all permission sets granted to it instead of granting them to the User Group.  This should add more controls and prevent the risk that you described.

Item 1 - is really no different than creating a top-level permission set to serve instead of the User Group level.  In fact, you might say it is more risky to use User Groups because of the issue the OP raised.

Item 2 - I totally get this and it makes a lot of sense.

Thanks for the info and explanation!

Cheers,

Nick