Skip to main content

Roles

Introduction to roles in ConSol CM​

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.
Assigning cases to oneself

If the users should be able to accept cases, i.e., assign cases to themselves, they need the Assign user 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 users

    info

    The user who should receive the case need 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 new contacts 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 TODO)
  • (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
More restrictive permissions

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 TODO)
  • (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 ConSol 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 TODO 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 a 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 on the Roles page. 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.

    info

    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

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.

Customer group permissions

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.

Global permissions

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.

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.

    warning

    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 TODO. Emails which are sent automatically when the user assignment at a case is changed, see TODO are also sent to the representative.