Roles
Introduction to roles in ConSol CM
Roles are used to bundle the permissions required for working with ConSol CM. The roles are assigned to users, who are granted the respective permissions.
Concepts, terms and definitions
Concept |
Other terms |
Definition |
---|---|---|
role |
|
Set of access permissions to objects and functions in ConSol CM. |
permission |
|
Right to view certain objects or perform certain actions in ConSol CM. |
queue permission |
|
Permission to access cases of a given queue. |
customer group permission |
contact group permission |
Permission to access contacts of a given contact group. |
resource type permission |
|
Permission to access resources of a given resource type. |
view |
|
Definition of the set of cases which are displayed in the case list in the Web Client. |
user function |
engineer function |
Capacity in which users can be added as additional participants to cases in the Web Client. |
user |
engineer |
User account for a person who works with the Web Client or Web Admin Suite. The permissions for the user account are defined by assigning roles. |
Purpose and usage
Roles are used to bundle permissions to objects and functions in ConSol CM. They are assigned to users in order to grant them the permissions included in the role. Users who do not have any role assigned can log in to the Web Client, but they can neither view objects nor perform any action. By default, access is blocked and it can only be granted via roles. A user can have several roles according to his capacity within the organization. The permissions from the different roles are added to define the final set of permissions for the user.
In addition, it is possible to assign views and user functions to roles. The users can select the views which are assigned to their roles in the case list. When users are assigned as additional participants to cases, they can receive the functions which are assigned to their roles.
During the initial setup of ConSol CM, an initial administrator role is created and assigned to the initial administrator user.
Available settings for roles
The definition of a role consists of assigning the required permissions, views and user functions. The permissions are grouped in four categories:
- Permissions for cases are managed in the Queue permissions tab.
- Permissions for contacts are managed in the Customer group permissions tab.
- Permissions for resources are managed in the Resource type permissions tab.
- Permissions for functions and actions within ConSol CM are managed in the Global permissions tab.
Click the number of permissions in the overview table to open the tab.
There are no further settings regarding views and user functions, which are simply assigned to roles.
Permissions for cases
Permissions for cases are called queue permissions because they are managed by queue. They always apply to all cases which are in the respective queue.
There are two general permissions regarding cases:
-
Role can create cases in this queue
Permission to create cases in the queue -
Other users can assign cases to users with this role
Permission to be the assigned user of a case. Cases can be assigned manually by a user or automatically by script.If the users should be able to accept cases, i.e., assign cases to themselves, they need the Assign permission.
The remaining permissions are defined depending on the assignment status of the cases. There are four status:
-
assigned to me
Cases assigned to the current user -
where I participate
Cases to which the user is assigned as an additional participant -
without assignee
Cases without assigned user -
assigned to colleagues
Cases assigned to other users
For each assignment status, the following permissions can be set:
-
View cases
Permission to view cases, i.e. to open a case and view its content -
Edit data
Permission to edit cases, i.e. to edit default fields and case fields in the header or details sections of a case -
Add content
Permission to add information (comments, emails, attachments, time booking entries) to a case -
Execute activities
Permission to execute workflow activities, i.e., move the case forward in the workflow -
Assign user
Permission to assign cases to oneself or other usersThe user who should receive the case has to have at least one role with the Other people can assign cases to this role permission.
-
Change participants
Permission to add an additional participant to a case -
Change queue
Permission to move cases from one queue to another queue. If this permission is granted, the Queue drop-down list is displayed in the case header. The drop-down list includes all queues for which the user has Change queue permissions. This means that the user needs the Change queue permission for cases with the same assignment status in the source as well as in the target queue.It depends on the workflow of the target queue where the processing of the case continues:
- If the source queue and the target queue share the same workflow, the case starts its processing in the target queue at its last position in the source queue.
- If the source queue and the target queue have different workflows, the case starts the process in the target queue at the start node.
Best practice
Only grant the Change queue permission if it is absolutely necessary and after carefully considering all side-effects. Usually it is not required and it can break the defined process chains. The recommended method to change the queue of a case is using jump-in and jump-out nodes within the workflow.
Permissions for contacts
Permissions for contacts are called customer group permissions because they are managed by contact group. They always apply to all contacts who belong to the contact group. Contact group permissions are required to create, view and edit the contacts who belong to the respective contact group.
A case always has a main contact. In order to view a case, the users need at least read permissions for the contact group which the case’s main contact belongs to.
The following permissions can be granted:
- Role can create contacts in this customer group
Permission to create a new contact in the respective contact group. In a two-level contact data model, this permission refers to both persons and companies. - View contacts
Permission to view the contacts - Edit data
Permission to edit contact data and to change the company of a person on the person page. - Delete contacts
Permission to delete contacts. This permission refers to both companies and persons. In case of persons, it allows to anonymize the person and to delete it both with related data and without related data. In addition, it also includes the permission to transfer the cases of a contact to another contact. - Execute activities
Permission to execute contact actions (see Contact actions) - (De)activate contacts
Permission to disable and re-enable contacts, so that no cases can be created for the contact. This permission refers to both companies and persons. In addition, it also includes the permission to transfer the cases of a contact to another contact. - View content
Permission to view the comments and attachments of the contacts. If this permission is not granted, the Comments and Attachments section is not displayed in the Web Client. - Add content
Permission to add comments and attachments to the contacts. If this permission is not granted, the Comments and Attachments section in the Web Client is read-only. - Delete content
Permission to delete comments or attachments in the Comments and Attachments section in the Web Client
You can enable the additional assignment status contacts of my cases by creating the system property my.customer.enabled from the module cmas-core-server with the value true. This allows to define a more restrictive permission model where the users can only access the contacts of their assigned cases. This requires additional checks for all contact searches and can lead to performance problems on large systems.
Best practice
Set up specific roles including only customer group permissions.
For each contact group, you can create one role with permissions to view the contacts and one role with full permissions. The role with view permissions is then assigned to all users who work with cases whose main contact belongs to the contact group. The role with full permissions can be assigned as needed to those users who are also allowed to edit contact data or create new contacts.
This approach can be helpful if not everyone is allowed to edit contact data.
Permissions for resources
Permissions for resources are called resource type permissions because they are managed by resource type. They always apply to all resources of the resource type.
The following permissions can be granted:
- View resources
Permission to view resources - Edit data
Permission to edit resource data - Delete resources
Permission to delete resources - Execute activities
Permission to execute resource actions (see Resource actions) - (De)activate resources
Permission to disable and re-enable resources - View content
Permission to view the comments and attachments of the resources. If this permission is not granted, the Comments and Attachments section is not displayed in the Web Client. - Add content
Permission to add comments and attachments to the resources. If this permission is not granted, the Comments and Attachments section in the Web Client is read-only. - Delete content
Permission to delete comments and attachments of the resources in the Comments and Attachments section in the Web Client. - Create resources
Permission to create new resources of the respective resource type.
Global permissions
The following permissions are available:
- Administrate full system + access all entities
Provides administrator access to the entire CM system, this applies to the Web Admin Suite and administrator access to the Web Client, including runtime data. Also see Defining additional administrator roles. - Administrate full system
Provides access to the complete system configuration in the Web Admin Suite, and the page customization, text templates and web forms in the Web Client. An administrator with this role does not have access to runtime data (runtime data in the Web Client and Case administration page. Also see Defining additional administrator roles. - Administrate users and roles
Provides access to the navigation group Access and Roles of the Web Admin Suite. Also see Defining additional administrator roles. - Read archived cases
Permission to view cases in CM/Archive. - Archive cases
Permission to archive cases. - Delete cases from the archive
Permission to remove cases from CM/Archive, i.e., delete them permanently. - Access archive statistics
Permission to display statistics in CM/Archive. -
Manage templates
Permission to manage templates in the Web Client. If this permission is granted, the menu items Text templates and Document templates are displayed in the Web Client. Please see Text templates and Document templates (CM/Doc) for further information about templates. -
Configure myself as representation for other users
If this permission is set, users with this role can configure themselves as a representation for other users. In the Web Client the users that can be represented by an user with this permission are shown in a list within the user profile.If this permission is not set, users can only configure other users as a representation for themselves.
Please see Configuring representations for details about the implications of using representations.
- Access cases of own company
This permission is only relevant for CM/Track user profiles, see Regular users vs. CM/Track profiles. CM/Track users with this permission are allowed to access all cases of the company which they belong to. Users without this permission only see their own cases.
Best practice
Set up a specific role for the users in charge of the text and document templates. Create a role with the permission Manage templates only and assign it to the users who create or edit templates.
Basic tasks
The basic tasks regarding roles are available in the menu item Roles. It shows a list of roles with the number of assigned users, permissions, and views. The main roles panel also allows to edit the name of a role, duplicate a role, or delete a role. You can find the respective icons on the right side of the row of the role.
Finding roles
There are three ways to filter the roles table:
-
Enter the name of the role in the search field to display only roles with a matching name.
-
Select a queue in the All queues filter to display only roles which include permissions for the selected queue.
-
Select a user in the All users filter to display only roles which are assigned to the selected user.
Managing roles
You can perform the following actions on roles:
-
Create a new role
Click the New role button and enter the name of the role. -
Change the name of a role
Click the Edit icon and enter a new name for the role in the Role name field. -
Delete a role
Click the Delete icon. The users who had this role assigned loose the respective permissions when they log in again. -
View the permissions of a role
Click one of the permissions columns of a role. In the Permissions panel on the right, you can select the tab of the type of permission which you want to view. -
Edit the permissions of a role
Click one of the permissions columns of a role. In the Permissions panel on the right, you can select the tab of the type of permission which you want to assign or unassign. Select the checkboxes of the desired permissions.The permissions are updated as soon as you check/uncheck them. They become active at the next login of the users with the role.
-
View the assigned users of a role
Click the Users assigned column. The assigned users are displayed in the Users with role panel. -
Assign a role to users
Click the Users assigned column and click the Assign users button, which is displayed above the search field in the Users with role panel. This opens a pop-up window where you can select several users on the left. The role is assigned to all the selected users. -
Remove users from a role
Click the Users assigned column. The assigned users are displayed in the Users with role panel on the right. Click the Minus icon next to the name of the user to remove the user from the role. To remove several users from the role at once, click the Assign users icon, which is displayed next to the search field. This opens a pop-up window where you can remove users from the role by clicking the X icon next to the name of the user. -
Assign views to a role
Click the Views assigned column and click the Assign views button, which is displayed above the search field in the Views of role panel. This opens a pop-up window where you can select several views. You can filter the views displayed in the drop-down list by queue.If the role is the main role of at least one user, you can sort the views to determine their order in the case list of the Web Client. Use the Sort order: up and Sort order: down buttons.
-
Remove views from a role
Click the Views assigned column. The assigned views are displayed in the Views of role panel on the right. Click the Minus icon next to the name of the view to remove it from the role. To remove several views from the role at once, click the Assign views icon, which is displayed next to the search field. This opens a pop-up window where you can remove views from the role by clicking the X icon next to the name of the view. -
Assign user functions to a role
Click the Functions assigned column and select the desired user functions in the Select user functions to assign to the role field. -
Remove user functions from a role
Click the Functions assigned column. The assigned user functions are displayed below the selector. You can remove them from the role by clicking the X next to the name of the user function.
Advanced tasks
The advanced tasks are related to roles but require additional configuration of items outside the role administration.
Defining the role concept
There a several approaches when it comes to designing a concept for roles. The appropriate approach depends on how the system is used. The following questions can be helpful for designing the role concept:
- Which teams work with ConSol CM? Should all team members have the same permissions?
- How is contact data maintained? Is everybody allowed to edit contact data?
- If CM/Resource Pool is used: How is resource data maintained? Is everybody allowed to edit resource data?
- Do you have any power users who are in charge of special tasks?
The following restriction applies:
- In order to view cases, the users need at least read permissions for the contact group which the cases’ main contact belongs to.
The following best practices have been proven useful:
- Queue permissions:
- Customer group permissions:
- Global permissions:
Best practice
Set up a specific role for the users in charge of the text and document templates. Create a role with the permission Manage templates only and assign it to the users who create or edit templates.
Best practice
Only grant the Change queue permission if it is absolutely necessary and after carefully considering all side-effects. Usually it is not required and it can break the defined process chains. The recommended method to change the queue of a case is using jump-in and jump-out nodes within the workflow.
Best practice
Set up specific roles including only customer group permissions.
For each contact group, you can create one role with permissions to view the contacts and one role with full permissions. The role with view permissions is then assigned to all users who work with cases whose main contact belongs to the contact group. The role with full permissions can be assigned as needed to those users who are also allowed to edit contact data or create new contacts.
This approach can be helpful if not everyone is allowed to edit contact data.
Defining additional administrator roles
There are three types of administrator permissions:
- Global administrator
Access to all configuration and runtime data. Permission: Administrate full system + access all entities - Configuration administrator
Access to all configuration data, no access to runtime data. Permission: Administrate full system - User administrator
Access to users, roles, views and user functions, no access to other configuration or runtime data. Permission: Administrate users and roles
There always needs to be at least one role with global administrator permissions and one user with this role. If required, you can create roles for additional administrators. This can be useful, for example, to create a user administrator role which can be assigned to the power users of the system. In this way, you can enable team leaders to create and delete users without giving them access to the rest of the configuration.
Impact on access and roles management
Administrators cannot assign roles or permissions of a higher level or manage users who have roles with higher level permissions. Therefore, some restrictions regarding role and user management apply for the configuration and user administrator. These administrators cannot perform the following actions:
- Add or remove higher level permissions to/from roles
- Assign roles containing higher level permissions to users or unassign them from users
- Manage roles containing higher level permissions (create, copy, delete)
- Manage users who have roles containing higher level permissions (edit, enable, disable, delete)
These restrictions apply to the following permissions:
Configuration administrator:
- Administrate full system + access all entities
User administrator:
- Administrate full system + access all entities
- Administrate full system
Configuring representations
Representations are set in the user profile of the Web Client. Every user can select another user with whom he has at least one role in common to represent him. Users who have roles with the Configure myself as representation for other users permission can also set themselves as a representation for other users.
Representations have several effects:
- The representing user can view the case list of the represented user using a special option in the case list.
- The representing user can receive a copy of the emails sent to the represented user through ConSol CM.
There are two different scenarios for sending emails:
-
A user writes an email using the email editor
It depends on the value of the property cmweb-server-adapter, forward.mails.to.representatives if the representing user receives a copy of the email. By default, this property is set to false, meaning that this email is not sent to the representing user. If the property is set to true, all emails which are sent manually from CM are sent to the original recipient and his current representative. The CM system checks if a representation rule is active for the recipient’s email address.Please inform your CM users about this behavior. It might lead to unwanted effects, especially when persons are registered as both users and as contacts in ConSol CM.
-
An email is sent automatically from the CM system
The email is not sent to the representing users automatically. It depends on the implementation of the script if the representing user receives a copy of the email. For details, please refer to Sending emails and notifications. Emails which are sent automatically when the user assignment at a case is changed, see Scripts and templates are also sent to the representative.