Exploring OTOBO

The core elements of OTOBO (agents, queues, groups, customers, customer users, tickets, types, priorities) ensure a smooth and organized customer support process and enable precise control of the service processes. The agents are the system users who process the tickets and communicate with customers. OTOBO supports agent management with various back-end sources, offering extensive integration options for managing the authorization system.

Queues organize the tickets and assign them to teams by skill levels, fields of responsibility, or departmental affiliations (Figure 1). Groups manage access and authorizations. When you assign agents to groups, you are coordinating access to tickets, functions, and areas within the system to create a secure and organized work environment.

Figure 1: The OTOBO customer portal provides an overview of the current tickets.

You can also manage customers and their users (customer users). This structure allows the processing of requests centrally and ensures that each finds the correct handler. The ability to use different data sources (e.g., databases and LDAP directories) for customer management massively boosts flexibility.

Tickets are the basis of communication in OTOBO. They record every request, problem, or case created by customers or created internally (Figure 2). Dynamic fields allow for detailed information on tickets, which in turn boosts data analysis and reporting capabilities. You can define ticket types (e.g., unclassified , incident , or problem ) to categorize requests. Moreover, the system uses a traffic light system to help you define priorities, ensuring that urgent requests receive immediate attention. In the default installation, tickets can have one of five priorities, but it is often sufficient to use just three.

Figure 2: In this screen, you create new tickets on the basis of a user's phone number.

Assigning agents to groups is essential for the efficient processing of tickets and requests. These assignments can include finely tuned permissions ranging from read-only access to full access and even specific actions such as entering notes or editing ticket priorities.

Microsoft 365 Link

The integration of email from Microsoft 365 into OTOBO by OAuth 2.0 offers a secure and state-of-the-art method for email retrieval. Getting this to work involves a few key steps, from setting up in Entra ID to configuring in OTOBO. I'll begin on the Entra ID side first:

1. Create an enterprise application. To begin, you need to create an enterprise application on the portal that represents your OTOBO instance in the Microsoft cloud and serves as the basis for authentication.
2. Create a redirect URL: For OAuth 2.0 authentication, you need to define a redirect URL that routes back to the OTOBO instance. This URL comprises the address of your OTOBO installation followed by /otobo/index.pl?Action=AdminMailAccount .
3. Generate a secret client key: You need to create this key in Azure to enable later authentication in OTOBO.
4. Add API authorizations: The app requires specific authorizations to access the email data. Authorizations for IMAP.Access-AsUser.All and POP.AccessAsUser.All are important.

After the setup in Entra ID, the next step is to complete the configuration in the OTOBO ticket system:

1. Install the MailAccount-OAuth2 package: In OTOBO, use the package manager to install this package to extend OTOBO to include the functionality it needs to use OAuth 2.0 for retrieving email.
2. Customize the OTOBO system configuration: In the system configuration, you need to enable the OAuth2::MailAccount::Profiles###Custom1 profile and configure the application ID, client key, and tenant ID. You also need to enter the specific TenantID instead of common in the AuthURL and TokenURL sections to ensure successful authentication.
3. Select the PostMaster mail account profile: Create an email account (or customize an existing one) by selecting the previously configured OAuth2 profile so the PostMaster process can use OAuth 2.0 to retrieve email from the Microsoft 365 account.

Make sure all required API authorizations are granted in Azure and your firewall is configured to allow communication with the Microsoft 365 servers. Without these steps, authentication could fail or email retrieval could be blocked.

Connect Active Directory

Integrating users from Active Directory offers an efficient approach to centralizing and simplifying user management in large organizations. After connecting an LDAP or Active Directory server, you can seamlessly transfer user data to the OTOBO system, eliminating the need for manual maintenance.

To begin, you need to prepare the LDAP back end in OTOBO for integration with Active Directory. The LDAP back end is configured in the Kernel/Config.pm configuration file, in which you store the LDAP server details. Please note that OTOBO's files are located in volumes because of the Docker installation, which explains why you will find the files in /var/lib/docker/volumes/otobo_opt_otobo/_data.

To customize the configuration, begin by copying the $Self->{CustomerUser} section from the Kernel/Config/Defaults.pm file to the Kernel/Config.pm file and remove the hashes (# ) to enable the required LDAP settings, including the server address (Host), base domain name (BaseDN), and user identification (UID), which is typically the sAMAccountName for AD integration. Next you need to adjust the attribute mappings between LDAP attributes and OTOBO-specific fields to ensure flexible handling of customer data, such as the assignment of the full name, email address, and other relevant customer data.

Additionally, OTOBO supports parallel use of different back ends to help you manage user data from multiple sources. If you number the back ends (e.g., CustomerUser1, CustomerUser2, etc.) in the Kernel/Config.pm configuration file, the ticket system can integrate up to 10 different back ends.

Active Directory integration also enables granular control of user authorizations within OTOBO. By assigning AD groups to OTOBO roles, you can map extensive access authorizations on the basis of existing company guidelines. Ultimately, this interaction ensures seamless synchronization of user data between the systems, reduces the administrative overhead involved in user management, and improves security through centralized authentication mechanisms.