What are Roles and Groups?
Roles & Groups are the way we organise and differentiate users in Claromentis, and they are managed in the People application.
Creating these sets of users allows us to give all members of that Role or Group access to content or specific abilities in one go.
This is done by selecting Roles & Groups in permissions boxes in applications across the site and giving them particular rights, which affect what they can see and interact with.
e.g. As seen for this News channel below, a mix of Roles & Groups have been entered to cover all the users I want involved, then I have given different permissions to each based on what I want them to be able to do in News:
Without Roles & Groups, we would have to enter each user's name individually into permissions boxes across the Intranet, which is not best practice and a massive time sink!
There is no limit on the number of Roles & Groups that can be created in the Intranet, and a user can be a member of multiple of each at any time.
Subsequently, Roles and Groups are vitally important to the management of your site and user access.
People administrators need to be confident in creating these, updating user membership and changing permissions across applications to include them where required.
Roles
We designed Roles to be used to encapsulate users for Intranet-specific tasks or responsibilities.
e.g. Intranet administrator, Policy managers, News Editors, Page editors, Content creators, etc
However, you have free rein to set up whatever Roles you like, as long as these differentiate users enough for effective use in permissions and their titles indicate who should be members.
Roles will always be created and managed locally by People administrators.
Create a new Role
An application administrator can head to Admin > People > Role to create a new Role.
The video below shows this process:
The new Role becomes available immediately after saving and can be used in permissions to give access to abilities straight away.
As shown in the video, the newly created Role was entered into the permissions for a News channel.
Please note: Creating the Role and adding users to this doesn't do anything alone; an administrator needs to place that Role into the permissions box to give its members access to that content or ability.
- Title of the role: The name of the role that will appear in the system (to administrators only)
- Extranet area: (Optional) If required, you can attribute the Role to an extranet, meaning only users part of that extranet can be chosen as members of the Role; otherwise, leave this set to 'none'.
- Description: (Optional) A brief description of the role
- Owner: The user who has created the role (will auto-populate but can be changed)
- Create date: The date the role was created (will auto-populate but can be changed)
When adding users to a Role, the 'Browse' function can be used instead to select members rather than typing in names and selecting them.
Users can be added to the Role at the point of its creation, but this can be changed at any time by a People administrator.
So if a new person joins your company or now has an extra responsibility, add them to the appropriate Role(s) and they will get all permissions and abilities across the site where those Role(s) have been entered.
Groups
Our intention for Groups is that they cover actual denominations of users relevant to your company, like the departments, organisational structure, geographical location, job titles, or sectors.
e.g. Marketing, Sales, Logistics, London Office, Milan Purchasers, Account Managers, Customer Success, Auditors, Site 405A, etc
However, you have free rein to set up whatever Groups you see fit in practice, as long as these differentiate users enough for effective use in permissions and their titles indicate who should be members.
⚠️ Groups can either be created and managed locally OR by a sync
If group sync is in use, the instructions below do not apply.
The team managing your sync can push new groups and update the user membership of them in the sync instead
Creating a new Group
First, check that your site is not using group sync before proceeding.
If you have no sync set up (the LDAP tool or the user sync module is not configured) or the LDAP tool is set up but without group sync, groups can be created and managed locally using the instructions below.
Head to Admin > People > Groups and click 'Add a new group'.
The video below shows this process:
The new Group becomes available immediately after saving and can be used in permissions to give access to abilities straight away.
As shown in the video, the newly created Group was entered into the permissions for a page, and its members were given the ability to edit it.
Please note: Creating the Group and adding users to this doesn't do anything alone; an administrator needs to place that Role into the permissions box to give its members access to that content or ability.
- Group name: The name of the group that will appear in the system (to administrators only)
- Parent group: (Optional) The parent of the new Group (the new group becomes nested within the parent)
- Description: (Optional) A brief description of the group
- Owner: The user who has created the group (will auto-populate but can be changed)
- Create date: The date the group was created (will auto-populate but can be changed)
Users can be added to the Group at the point of its creation, but this can be changed at any time by a People administrator.
So if a new person joins your company or now has an extra responsibility, add them to the appropriate Group(s) and they will get all permissions and abilities across the site where those Group(s) have been entered.
Group +
Unlike Roles, Groups (created locally and not by a sync) can be nested within each other.
This is applied using the 'Parent group' field when creating a group.
Nesting groups within each other changes how the groups are listed in the Group tab (Admin > People > Groups)
Nested groups are denoted by the indentation shown in the diagram below:
It is perfectly fine to create all your groups with no nesting, but it can be beneficial if your structure calls for it.
The only element that creating nested groups changes is the appearance of 'Group[+]' in permissions when selecting Groups.
This option will only appear against groups that have been nested and allows you to bring in nested groups when defining permissions, rather than entering each group at each level separately.
Essentially, it determines at what point in the nested structure you want to bring in permissions for, and it will include every group below that.
e.g. Review the nested group structure shown here:
In permissions, if I enter 'Group[+]: Development', this includes itself and all nested groups below it, so in this case, the users in the 'Testing' group are also included:
In contrast, using 'Group: Development' only brings in the users who are members of that group.
Using 'Group[+]: Development' means I can include its nested groups without adding the subgroups individually.
If you nest your groups, People administrators need to be aware of what the 'Group[+]' options mean so they make the correct selections when entering these for permissions and do not accidentally give more users access to something than they expected.
All Registered
You may have already noticed this group across permissions when onboarding with us, or using a demo site:
This is a hardcoded group installed with Claromentis, and it includes every user account created on a site by default.
This is not a group that will appear in Admin > People, and its members cannot be edited.
It automatically updates to include all user accounts and allows your administrators to effortlessly set permissions for all users without having to create your own group for this manually.
In some applications, 'All registered' is entered by default when something is created, e.g. new menu items, visibility on icons in the application list, but can always be removed if not appropriate.
This is because generally most content on your site will be viewable to everyone so 'All registered' can be used to give access.
It's only when we want to exclude users or apply a difference in abilities in an application beyond being able to just 'view' that Roles & Groups are additionally entered.
