User Groups
User groups control the central rights management within the system.
The structure is deliberately simplified to allow an uncomplicated use of the system.
The administrator for master data (members of the groups "Administration - Full" and "Administration - Master data") can add any user to any group.
It is technically and commercially irrelevant which users get which permission groups. The recommendation is not to give each user administrator rights so that no uncoordinated changes in system processes occur.
Standard user groups
The following standard user groups are available in the delivery:
•Administration – Asset Management: The group has access to and can administer the objects of the Asset Management DB, such as asset types and attributes.
•Administration – Master data: Includes the authorization to create and adjust master data.
•Administration – Full: This group has full access to all administration settings (default role of the administrator). An administrator does not automatically have the permission to enter and process tickets. For this purpose, he/she has to be assigned to the corresponding user group separately.
•Asset manager: Maintains extended access to the asset database and is notified by e-mail, for example, when the asset inventory falls below the minimum level.
•eCAB participant: This group inherits all permissions of the "Ticket user" group and can additionally be used to approve changes, for example.
•Security manager: This group has all permissions of the "Ticket Manager" group and can be used for security incidents, for example.
•Ticket user: The group contains all necessary permissions to create and edit tickets (default group for service desk employees).
•Ticket manager: Ticket managers have all the rights of ticket users and additionally extended rights for editing tickets and access to the task board as well as the KPI monitor. For example, the group can view the ticket history as well as the total SLA times. In addition, tickets in the "Completed" state can be manually reopened or closed (default group for managers).
Individual user groups
It is possible to create any additional individual user groups, but these are always a subgroup of one of the available standard groups and inherit their basic permissions accordingly. Therefore, when creating a new user group, always select a parent from the existing groups. Thus, the group structure with individual groups always results in a tree structure.
Restricting the visibility of tickets based on the group structure
When using the ticketing system with different ticket types in multiple teams, a frequent requirement - depending on the individual organizational structure - is that users from one team are not allowed to see tickets from another team and vice versa. In addition, there are overlapping users who need an overview of all tickets.
This can be achieved very easily in the ticketing system by assigning users to different groups or subgroups. The field "Responsible group" in the ticket thus automatically controls which user is allowed to see which ticket.
Basically, all users of a group will see all tickets of the assigned group and its subgroups, even if a ticket is additionally assigned to a certain user as responsible. This ensures that, for example, a ticket can easily be taken over by another user of the same group if a user is absent.
|
Note: The visibility rules for users based on the assigned groups only affect tickets and emails assigned to these tickets. Other areas such as the knowledge base and the asset DB are accessible for all users or only restricted via the basic role-oriented permission groups (administrator, manager, etc.).. |
Below are some examples of how the group structure can be used to delimit tickets in terms of their visibility between user groups:
Example 1: There are several teams within the IT department. These teams should only see and process the tickets that are assigned to them responsibly. However, the IT manager or IT team leader should see all tickets across the board.
Implementation:
•A new user group has to be created for each team as a subgroup of the standard group "ticket users".
•The users for the individual teams must be assigned to the corresponding sub-groups and must not be assigned directly to the "Ticket users" superficial group.
•The team leader with an overall view of all tickets, who is to have the "Ticket manager" permission, must only be assigned to the standard "Ticket user" superficial group and the standard "Ticket manager" group
Example 2: In addition to IT tickets, HR tickets are also to be processed with the ticketing system. The HR tickets and associated communications may only be seen by users from the HR area. Conversely, HR users are not allowed to see IT tickets. The two areas also each have their own team leaders.
Implementation:
•A new user group must be created for each team as a subgroup of the default "Ticket Users" group ( IT Team(s) and HR Team(s) ).
•The users for the individual teams must be assigned to the corresponding sub-groups and must not be assigned directly to the "Ticket Users" superficial group
•The team leader with overall view on all tickets of the IT who should have the permission "Ticket Manager" must only be assigned to each IT user group (or you create for the case again a separate superficial group via the IT groups) and to the standard group "Ticket Manager
•The same applies to a team leader for the HR tickets for the HR groups.
For better usability, if complex group structures are defined, a flat list of all user groups AND a tree-view list of sub-groups and their assigned users is displayed in this section.
Further setting options for user groups
•E-Mail behavior: a specific group e-mail address can be stored for each group. In case of automatic information via e-mail to the group, it can be defined whether the group e-mail or each assigned user of the group should be informed individually about the respective individual e-mail address. Furthermore, a standard outgoing e-mail account can be stored for each group.
•Ticket settings: For each group, you can restrict whether a member of this group may only submit a ticket to certain other responsibilities (the restrictions of all groups in which the user is registered apply). If there are to be restrictions, these must be maintained in the respective group in the list. If no group is entered in the list, the ticket can be submitted to any group in the ticket system
Teams
Besides user groups, it is also possible to define individual teams. Teams can consist of people and users. These teams can thus be used at different points in the system to simplify and structure administration.
Example Use Case: Approvers for a certain topic consist of a defined group of several persons. To avoid having to define them individually as approvers, they can be put together in advance as a "team" and stored accordingly in the approval model. Changes to teams thus also have a direct effect on the points of use. Another example of a team is stakeholders for a specific topic who need to be written to from tickets.
A team can be composed of persons and users and a corresponding team title can be assigned for administration. An optional team email address can be stored (e.g. Exchange group address, if available), but the team members are always informed individually as well.