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
1. Directly on their user profile from the admin side
Open their profile from Admin > People
2. By opening the Role or Group from the corresponding tab on the admin side
Open the Role or group in Admin > People
3. By performing an export of the Role and Group fields for all users
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
1. Directly on their user profile from the admin side
A People administrator can update user roles or group membership directly on their profile from the admin side using the tabs.
2. By opening the Role or Group from the corresponding tab on the admin side
3. By importing a CSV of changes to the Role and Group fields for users
They can also do this en masse using a CSV export and import of users, where the CSV determines all the role and group membership changes.
For Roles or groups that have less than 100 users, membership can also be updated from Admin > People > Role or Group.
- If Group sync is enabled
User membership cannot be updated in the Intranet at all(e.g. making changes on on user rpfiles, in thr groups tab or using a csv will not work and in fact be reverted on the next sync)
Instead, your team must update the external repository first.
Once the change has been made there, they can either wait for the next scheudled sync to run, or a sync can be triggered from Admin > People > Synchornise > Click 'Reset'.
After the sync has completed, check the areas to see if the updates applied as expected.
Changes over time
It is recoomend that the users involved in managing and will be makig the changes there are made People administrators in the Intranet.
This allwos them to trigger the sync and test issues quickly rather than relying on other accounts to do this for them.
Also, it is important that the changes made externally are updated
It is also iomportant that the users managing understand the change sthey make to syncing group memerhip will affect the intranet on the next sync so communication between teams is paramount o ensure user access remain unchanged, or only change in an expected way.
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 they previously could.
In this scneario 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 this user has permission to view the project in the first place.
Checking the project role permissions, the user has not been directly specified, therefore we need to check if they are included by any of the roles and groups that have been entered.
To do so, a People administrator can locate the user profile on the administrative side of People.
From there they can click on the role and group tabs to reveal the user's membership:
This can be crossed referenced with the entries into the InfoCapture project permissions 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 their profile specifically or a role/group they are part of (if appropriate and missing) to give them rights or update rights if the role/group they are included in was already specified.
