Skip to content

OTOBO – Groups, Roles & Agents

OTOBO is a flexible and scalable ticket system characterized by fine-grained rights management. Through the targeted use of groups, roles, and agents, you can streamline processes, clearly define responsibilities, and increase system security within your company.

Below is a schematic diagram illustrating the fundamental relationships between agents, groups, roles, queues, customers, and customer users in OTOBO.

flowchart LR
  Agent[Agent] -->|Member of| Gruppe[Group]
  Gruppe -->|Assigned roles| Rolle[Role]
  Rolle -->|Authorized access to| Queue[Queue]
  Kunde[Customer] -->|Contains| Kundenbenutzer[Customer User]
  Kundenbenutzer -->|Member of| Gruppe

Groups are the heart of access control. They bundle users together and determine which functions and queues they have access to by default.

In its delivery state, OTOBO includes several predefined groups. You can use these directly or customize them as templates for your own groups.

These groups control which customer users have access rights to customer portals and data.

Customer User Group Default

Predefined customer user groups in OTOBO

These groups allow for dynamic field preferences to be implemented per user group.

Dynamic Field Preferences Groups

Example of dynamic field preferences

Standard groups used on the customer side to structure tickets and requests.

Customer Group Default

Predefined customer groups after installation

Overview of the interaction of all three components in the system context.

Gruppen, Rollen & Agenten Übersicht

Diagram: Interaction of groups, roles, and agents

Groups are created and maintained via the Users, Groups and Roles → Groups module.

ActionDescription
Add groupOpen the link in the left sidebar, enter mandatory fields, click Save.
Edit groupSelect group, change data, click Save or Save and finish.
Deactivate groupSet Validity to invalid or invalid-temporarily.
SearchUse the filter field for group names.
FieldMeaning
NameUnique designation, visible in overviews and dropdowns.
ValidityOnly valid groups are actively usable.
CommentShort description or notes regarding the group.

Roles bundle individual permissions into profiles that you assign to users or groups. This increases clarity and reduces the effort required for rights changes.

In the Users, Groups and Roles → Roles module, you manage the creation, editing, and deactivation of roles.

Connects a role with one or more groups to delegate rights.

Rolle zu Gruppe

Interface: Role assignment to groups

Roles can inherit from each other to modularize permission profiles.

Rolle erbt Rolle

Representation of the role hierarchy

Agents receive their individual permissions through this assignment.

Agent zu Rolle

Assignment of roles directly to agents

In special cases, agents can obtain specific rights from each other.

Agent zu Agent

Example: Agent-to-agent permissions

Overview page for the central management of all agent and role assignments.

Agenten-Rollen-Management

Central dashboard of agent rights

Creating new roles with predefined permission sets.

Rolle hinzufügen

Step: Create new role

Adjustment of existing roles, e.g., to add new permissions.

Rolle bearbeiten

Step: Edit role

Detail view to control which groups receive which roles.

Rollen-Gruppen-Verwaltung

Area: Fine-grained assignment of groups to roles

Complete list of all defined roles, including filter and search functions.

Rollen-Übersicht

Management page of all roles in the system

  1. Add role in the left sidebar.
  2. Fill in role name, validity, and required fields.
  3. Click Save.
StepAction
SelectionClick on the role in the list.
AdjustmentChange fields as needed.
SaveSelect Save or Save and finish.
FieldMeaning
NameVisible designation in overviews and dropdowns.
ValidityOnly valid roles are actively assignable and usable.
CommentOptional note text regarding the role.

A complete list of standard permissions that you can use in roles and groups:

CodeDescription
roRead-only access to tickets.
move_intoMove tickets.
createCreate tickets.
noteAdd notes to tickets.
ownerChange ticket owner.
priorityAdjust ticket priority.
rwFull access to tickets (Read & Write).
chat_observerChat observer role.
chat_participantParticipation in chats (after invitation).
chat_ownerFull control over public chats.
statsAccess to statistics.
bounceBounce emails.
composeCompose replies.
customerChange customer information.
forwardForward messages.
pendingMark tickets as pending.
phoneAdd phone calls to tickets.
responsibleChange responsible agent.

The following sequence diagram illustrates the assignment process:

sequenceDiagram
  Agent->>Gruppe: Membership
  Gruppe->>Rolle: Role assignment
  Rolle->>Queue: Permission for queue access
  Kunde->>Kundenbenutzer: Contains
  Kundenbenutzer->>Gruppe: (optional) Membership

With this content addition and the explanatory image captions, every image is meaningfully embedded and clearly explained. Good luck with your further documentation!

Frequently asked questions

How do groups, roles, and agents interact within OTOBO to manage access and permissions?

In OTOBO, agents are the individual users who interact with the ticket system. They are organized into groups, which serve as the fundamental unit for access control. Groups bundle agents together and determine their default access to various functions and queues. Roles are then assigned to these groups, or sometimes directly to agents, to grant specific permissions. Roles encapsulate individual permissions into reusable profiles, making rights management more efficient and clear. This hierarchical structure ensures that agents receive the appropriate access rights based on their group memberships and assigned roles. Additionally, customer users can also be members of groups, linking their portal access and data rights to this system. This strategic use of groups and roles helps streamline processes, define clear responsibilities, and enhance system security.

What is the primary function of groups in OTOBO, and how are they managed?

Groups are the cornerstone of access control in OTOBO, designed to bundle agents and customer users, thereby defining their default access to various system functions and queues. They provide a structured way to manage who can do what within the ticket system. OTOBO includes several predefined groups upon installation, which can be used directly or customized as templates. These include Default Customer-User Groups for customer portal access, Dynamic Field Preferences Groups for user-specific field settings, and Default Customer Groups for structuring customer-side tickets. Groups are managed via the Users, Groups and Roles → Groups module. Here, administrators can add new groups by filling in mandatory fields like Name and Validity, edit existing ones, or deactivate groups by setting their validity to invalid or invalid-temporarily. The Comment field allows for additional descriptive notes.

What are OTOBO roles, and how do they simplify permission management?

OTOBO roles are profiles that bundle individual permissions, allowing for efficient and clear rights management. Instead of assigning numerous individual permissions to each agent, roles enable administrators to create predefined sets of permissions that can then be assigned to groups or directly to agents. This modular approach significantly reduces the effort required for rights changes and increases clarity across the system. Roles can also inherit permissions from other roles, further modularizing permission profiles and simplifying complex setups. Management of roles occurs in the Users, Groups and Roles → Roles module. Here, new roles can be created by specifying a Name, Validity, and an optional Comment. Existing roles can be edited to adjust their permission sets. Key assignments include Role ↔ Group (connecting a role with groups to delegate rights), Role ↔ Role (for inheritance), Agent ↔ Role (for individual agent permissions), and Agent ↔ Agent (for special cases of peer-to-peer rights).

Can you explain the different types of default groups available in a standard OTOBO installation?

Yes, OTOBO is shipped with several predefined groups that serve as practical templates or can be used immediately to structure your access control. These default groups are categorized to address different aspects of user and customer management:

  • Default Customer-User Groups: These groups are crucial for controlling which customer users have access rights to customer portals and specific data. They ensure that customer interactions are managed securely and appropriately.
  • Dynamic Field Preferences Groups: These groups enable the implementation of dynamic field preferences tailored to specific user groups. This allows for customized user interfaces and workflows based on group membership.
  • Default Customer Groups: Used on the customer side, these standard groups help organize tickets and requests, providing a clear structure for customer-related activities. Utilizing or adapting these default groups allows for a quick and efficient setup of OTOBO's access control mechanisms.
  • Groups, Roles & Agents - OTOBO Docs - Softoft
What are some common permissions available in OTOBO, and how are they applied?

OTOBO provides a comprehensive set of standard permissions that can be bundled into roles and assigned to groups or agents to define their access levels. These permissions cover a wide range of actions within the ticket system. Examples include:

  • ro: Read-only access to tickets.
  • rw: Full access to tickets, encompassing both read and write capabilities.
  • create: Permission to create new tickets.
  • move_into: Ability to move tickets between queues.
  • note: Permission to add notes to tickets.
  • owner: Authority to change a ticket's owner.
  • priority: Permission to adjust a ticket's priority.
  • stats: Access to system statistics.
  • chat_observer, chat_participant, chat_owner: Permissions related to observing, participating in, or owning chats.
    Other permissions like bounce, compose, customer (to change customer information), forward, pending, phone, and responsible (to change responsible agent) are also available. These permissions are typically assigned by adding them to roles, which are then linked to groups or individual agents, ensuring granular control over system functionalities.
  • Groups, Roles & Agents - OTOBO Docs - Softoft
  • OTOBO Administration Manual
How do I add or manage groups and roles in OTOBO's administration interface?

Both groups and roles are centrally managed within OTOBO's administration interface, specifically under the Users, Groups and Roles section. To manage groups, navigate to Users, Groups and Roles → Groups. Here, you can add a group by clicking the link in the left sidebar, entering a unique Name and setting its Validity, then clicking Save. To edit an existing group, select it from the list, modify the desired data, and click Save or Save and finish. Groups can also be deactivated by changing their Validity to invalid or invalid-temporarily. For roles, the process is similar: go to Users, Groups and Roles → Roles. To add a role, use the left sidebar link, fill in the Name, Validity, and any Comment, then Save. To edit a role, select it from the overview, make your adjustments, and Save or Save and finish. The Name and Validity fields are crucial for both groups and roles, determining their active usability within the system.