Roles and Groups are created and managed by People administrators.
They are used in permissions boxes across applications to give access to content or specific abilities in the Intranet.
Due to this, it's really important that user membership of Roles and Groups is being effectively managed by administrators, otherwsie an unexpected change in user access or abilities can be seen.
This guide will cover how an administrator can check or change a user's Role and/or Group membership.
How to check a user's Role & Group membership
A People administrator can access the admin side of People (Applications > Admin > People) to check any of the following areas:
1. Directly on their user profile
2. In the list of users on the admin side when 'Role' & 'Group' have been set to appear in this area by an administrator
3. By opening the Role or Group tabs and the 'User' sections
4. By performing an export of the Role and Group fields and downloading a CSV
How to update a user's Role or Group
As outlined in our guide here, Roles are always created and managed locally in the intranet.
Whereas, Groups can be managed locally in the same way OR by a sync.
A sync changes how Groups are created and how user membership can be updated.
Before proceeding, first identify if Group sync is enabled on your site or not, and follow the appropriate advice below.
- If Group sync is disabled/not configured
Both Roles & Groups can be updated by a People administrator from Admin > People in the following areas:
1. Directly on their user profile (click 'update' after changes to apply)
2. By opening the Role or Group tabs and the 'User' sections
(This option will only be possible for Roles & Groups of 100 users or fewer)
Users can be added by typing their name and selecting them or using the 'Browse' feature.
3. Using a CSV import
Ensure your CSV includes 'username' alongside the 'Role' & 'Group' data for the import to be successful.
Role & Group titles must match how they are in the Intranet exactly. Separate entries with a comma and a space.
Imports are additive, meaning previous membership will not be overwritten; what is in the CSV will be added to their profile.
So, your import can just contain changes; current membership does not need to be specified per user, as it will be retained after the import.
- If Group sync is enabled
Roles can be updated by a People administrator from Admin > People as outlined above, but Group membership cannot be; this is instead controlled by the sync.
If your team apply changes to Groups in the Intranet using the same steps for Roles (e.g. making changes to user profiles, in the groups tab or using a CSV) these changes will be reverted/removed on the next sync.
Once changes have been made there, your team can either wait for the next scheduled sync to run, or a sync can be triggered from Admin > People > Synchronise > Click 'Reset'.
After the sync has completed, check the user profiles from Admin > People areas to see if the updates applied as expected.
Changes over time
It is recommended that the users managing your external repository tied to the sync are made People administrators in the intranet.
This means they can trigger a sync in the intranet when required and test issues quickly, rather than relying on other People administrators who cannot access the external repository to do this for them.
It is also important that the users managing understand that the changes they make to syncing group membership will affect the intranet on the next sync, so communication between teams is paramount to ensure user access remains unchanged, or only changes in an expected way.
e.g If they remove a user from a group, after the sync, this is updated in the Intranet so that the user will no longer be a member and lose all access and permissions that group was previously giving them.
Why checking a user's Role or Group membership can be useful
As an administrator, sometimes users will report not being able to access content they could before, or they cannot perform an ability that they now need to.
In this scenario, you need to check which Roles and Groups they are in and then compare this to what has been set up in the application they are reporting an issue with to determine what is affecting them.
For example, a user reports they are not able to see tickets submitted in InfoCapture when following a link someone else has sent them.
The best place to start here is to confirm that this user has permission to view the project in the first place.
Checking the project role permissions, the user has not been directly specified; so next check if they are included by any of the Roles or Groups that have been entered.
Find the user's profile on the admin side of People and check which Roles & Groups they are in.
Check this against those entered into the application you are interested in to determine if the user reporting access issues is included or not.
Once this is known, the solution to rectify this should be clear, e.g. add them to permissions either by their name, a Role or Group they are in (if appropriate to give all other members the same rights) or by adding them to a Role or Group that is already specified with the desired abilities.
This advice applies to all applications and permissions boxes.
