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:

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:

The remaining permissions are defined depending on the assignment status of the cases. There are four status:

For each assignment status, the following permissions can be set:

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:

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:

Global permissions

The following permissions are available:

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:

Managing roles

You can perform the following actions on roles:

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:

The following restriction applies:

The following best practices have been proven useful:

Defining additional administrator roles

There are three types of administrator permissions:

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:

These restrictions apply to the following permissions:

Configuration administrator:

User administrator:

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:

There are two different scenarios for sending emails: