last updated on 04.11.20
The inSided platform knows two different kinds of roles, primary roles and custom roles. This topic will explain what the different roles are doing, as well as offer tips on how you can use roles to group certain users and explain what the advantages of it are.
Why do we need roles?
Roles are there to identify different types of users. For many different reasons you want to categorize people on the community. Let''s start with primary roles, as these ones are the same across all communities.
Primary roles
Primary roles can be found and changed in a user profile page in the Control Environment (under [Users] - [Users overview]).
Every user on the community owns such a role. Here are the different primary roles available:
Primary Role | Role Description |
---|---|
Registered user | This primary role is the standard role of every regular user on the community. |
Users awaiting E-mail confirmation
| This role is automatically assigned when a user has freshly registered on the community, but not have clicked on the activation link in his registration email yet. Usually these users are not able to start topics or respond until they have activated their account. *only for communities that do not use SSO login |
Waiting for moderator approval | This role is rarely used, as it only applies for communities where every new registration has to be approved by a Moderator. This is something that could be interesting for closed communities, or communities where you want to control who is registered. Users with this role usually only can see categories and topics, but not post in them.
|
Unregistered / not logged in | This role is for all the visitors that are not registered. This role is (usually) not assigned to any account, as they are not registered. |
Banned users | These are the bad boys of your community. |
Super user | This role is for the heroes of your community. Those who are very active, have a lot of knowledge and the right attitude. With this role they are able to mark a response in a question as the correct solution, they also do not have a limit on editing their posts (60 min by default). Also, their posts will not be touched by the spam detection (should this be activated on your community). |
Moderators | Moderators have access to most of the features available in the Control Environment, but not to everything. They can moderate content, ban users, create and assign Post Fields, and much more. Check this announcement to see which areas Moderators can access and which not. |
Community Managers & Administrators | As you probably would expect, Community Managers and Administrators have full power over a community. Besides the features available for Moderators, there are a number of features in the Control Environment which are exclusive for the Community Managers & Administrators:
|
Custom roles
Custom roles can be created and changed in a dedicated page in the Control Environment (found under [Settings] - [User roles]), if you want to check which users own a custom role, this can be found in the user overview ([Users] - [Users overview]).
Now custom roles are a very different thing. Before we speak about this, it''s important to understand the following things about custom roles:
- They sit "on top" of primary roles. All users have a primary role, regardless if they have custom roles or not.
- The primary role is leading. If the primary role allows you to do something, a custom role will not be able to take this right away from you.
What does a custom role that a primary role does not do?
That is a very good question. Basically, custom roles are being used for various things. While primary roles are very good to manage larger groups of users, custom user roles will enable you to create and manage smaller user groups. You can even equip them with more detailed rights (or restrictions). The most important and common use cases are:
1. Access management in the control environment
While both handle a users'' access rights on a community, custom roles will enable you to define much more specifically which parts a user might have access to in the control environment.
2. Access management in the front-end
You can use custom roles to give people access / posting rights in subforums in the front-end.
3. Give users (or colleagues) specific ranks on your community
'