en	Contents

en	Administration Area

en	Any system requires configuration. Configuring a system should be an easy task and the tools for configuration fit-for-purpose.

en	OTOBO offers several administration tools to configure, monitor, control and extend OTOBO.

en	Administration

en	Calendars

en	When working with customers, resource planning and scheduling can be a complex task. Appointments enable you to meet your customers where and whenever needed.

en	OTOBO supports this requirement with calendars. Calendars allow management of appointments and resources inside the ticket system. You can connect your tickets to scheduled tasks and make them available to all users to see. This feature adds transparency to show your teams workload and prevent users from promising resources which are not available.

en	Use this screen to manage calendars in the system. A fresh OTOBO installation contains no calendars by default. The calendar management screen is available in the *Calendars* module of the *Administration* group.

en	Calendar Management Screen

en	Manage Calendars

en	To add a new calendar:

en	Click on the *Add Calendar* button in the left sidebar.

en	Fill in the required fields.

en	Click on the *Save* button.

en	Add New Calendar Screen

en	Calendars can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit a calendar:

en	Click on a calendar in the list of calendars.

en	Modify the fields.

en	Click on the *Save* or *Save and finish* button.

en	Edit Calendar Screen

en	To export a calendar:

en	Click on the export icon in the list of calendars.

en	Choose a location in your computer to save the ``Export_Calendar_CalendarName.yml`` file.

en	To import calendars:

en	Click on the *Browse…* button in the left sidebar.

en	Select a previously exported ``.yml`` file.

en	Click on the *Overwrite existing entities* checkbox, if you would like to overwrite the existing calendars.

en	Click on the *Import Calendar* button.

en	If several calendars are added to the system, use the filter box to find a particular calendar by just typing the name to filter.

en	Calendar Settings

en	The following settings are available when adding or editing this resource. The fields marked with an asterisk are mandatory.

en	General Calendar Settings

en	Calendar name \*

en	The name of this resource. Any type of characters can be entered to this field including uppercase letters and spaces. The name will be displayed in the overview table.

en	Color \*

en	The calendar color that will be displayed in the calendar overview screens.

en	To change the calendar color, just select a new color from the color palette. You can chose from the pre-selected colors or define other colors by choosing it from the color selector or typing the hexadecimal value.

en	Permission group \*

en	Select which :doc:`../users-groups-roles/groups` can access the calendar.

en	Depending on the group field, the system will allow users the access to the calendar according to their permission level.

en	Read only: users can see and export all appointments in the calendar.

en	Move into: users can modify appointments in the calendar, but without changing the calendar selection.

en	Create: users can create and delete appointments in the calendar.

en	Read/write: users can manage the calendar itself.

en	Validity \*

en	Set the validity of this resource. Each resource can be used in OTOBO only, if this field is set to *valid*. Setting this field to *invalid* or *invalid-temporarily* will disable the use of the resource.

en	Calendar Ticket Appointments

en	Define rules for creating automatic appointments in this calendar based on ticket data. To add a new rule, click on the *Add Rule* button.

en	Calendar Settings - Ticket Appointments

en	Start date

en	Select a start date for the ticket appointment.

en	End date

en	Select the end date for the ticket appointment.

en	Queues \*

en	Select one or more queues to narrow down for which tickets appointments will be automatically created.

en	Search attributes

en	Additional search attributes can be added for further filtering by selecting an attribute and clicking on the ⊞ button.

en	Import Appointments

en	If at least one calendar have been added to the system, it is possible to import some appointments into the calendar.

en	To import some appointments:

en	Click on the *Import Appointments* button in the left sidebar.

en	Upload an iCal file and select a calendar.

en	Click on the *Import appointments* button.

en	Import Appointments Screen

en	Upload \*

en	Click on the *Browse…* button, and select a valid iCal (``.ics``) file to upload.

en	Calendar \*

en	Select an available calendar.

en	If desired calendar is not listed here, please make sure that you have at least *create* permissions.

en	Update existing appointments?

en	If checked, all existing appointments in the calendar with same ``UniqueID`` will be overwritten.

en	FAQ Category

en	Use this screen to manage categories available in FAQ articles. The FAQ package can be installed from the OTOBO addons repository with the :doc:`package-manager`. A fresh OTOBO installation already contains a category by default. The category management screen is available in the *FAQ Category* module of the *Administration* group.

en	FAQ Category Management Screen

en	Manage FAQ Categories

en	To add a category:

en	Click on the *Add category* button in the left sidebar.

en	Click on the *Submit* button.

en	Add Category Screen

en	To edit a category:

en	Click on a category in the list of categories.

en	Edit Category Screen

en	To delete a category:

en	Click on the trash icon in the list of categories.

en	Click on the *Yes* button in the confirmation dialog.

en	Delete Category Screen

en	FAQ Category Settings

en	Name \*

en	Subcategory of

en	It is possible to add the new category under an existing one as sub-category. This will be displayed as *Parent Category::Child Category*.

en	Permission \*

en	Agent groups that can access articles in this category.

en	Validity

en	Comment \*

en	Add additional information to this resource. It is recommended to always fill this field as a description of the resource with a full sentence for better clarity, because the comment will be also displayed in the overview table.

en	FAQ Language

en	Use this screen to manage languages available in FAQ articles. A fresh OTOBO installation already contains some languages by default. The language management screen is available in the *FAQ Language* module of the *Administration* group.

en	FAQ Language Management Screen

en	Manage FAQ Languages

en	To add a language:

en	Click on the *Add language* button in the left sidebar.

en	Fill in the required field.

en	Add Language Screen

en	To edit a language:

en	Click on a language in the list of languages.

en	Modify the field.

en	Edit Language Screen

en	To delete a language:

en	Click on the trash icon in the list of languages.

en	Delete Language Screen

en	FAQ Language Settings

en	The following setting is available when adding or editing this resource. The fields marked with an asterisk are mandatory.

en	The `ISO 639-1 code <https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes>`__ of a language.

en	Import/Export

en	Package Manager

en	OTOBO is a modular system that can be extended by adding additional software packages to the framework. Administrators are provided with an easy way to see which features are installed in which version and for sure to add, update and remove packages. OTOBO uses a package manager to perform all package-related activities as mentioned above in the graphical interface.

en	The package manager is listed in the *Package Manager* tile of the *Administration* group of the Admin Interface. Use this interface to install, remove and manage packages that extend the functionality of OTOBO.

en	Package Manager Screen

en	You may view the package documentation of each package even prior to installation by clicking the PDF-symbol next to the package name.

en	Install Packages

en	You have two options to install new packages to your OTOBO, either from an online repository or by installation of a local package file. You should prefer package from an repository as it eases consuming of updates if available.

en	The installation of packages not verified by Rother OSS is possible by default. We love open source. You can deactivate the installation of not-verified packages in the system configuration setting ``Package::AllowNotVerifiedPackages``.

en	Install from Repository

en	To install a package from an online repository, follow these steps:

en	Select an online repository from the drop-down in the left sidebar. The Rother OSS repository is configured by default.

en	Click on the *Update repository information* button to refresh the available package list.

en	Select a package from the *Online Repository* widget and click on the *Install* in the last column.

en	Follow the installation instructions.

en	After installation, the package is displayed in the *Local Repository* widget.

en	Online Repository Widget

en	The repository list can be changed in system configuration setting ``Package::RepositoryList``.

en	Install from File

en	Sideloading packages is also posible. To install a package from file follow these steps:

en	Select an ``.opm`` file from your local file system.

en	Click on the *Install Package* button.

en	Local Repository Widget

en	Reinstall Packages

en	If at least one of the package files are modified locally, the package manager marks the package as broken. You may overwrite these modifications by a reinstall.

en	To reinstall a package:

en	Select the package from the *Local Repository* widget that are marked for reinstall.

en	Click on the *Reinstall* link in the *Action* column.

en	Update Packages

en	Using the online repository to install packages, provides you a hint, if an update to the package is available in the *Action* column. To update a package from online repository follow these steps:

en	Check the available packages in the *Online Repository* widget for *Update* in the *Action* column.

en	Click on the *Update* link.

en	Follow the update instructions.

en	After updating, the package is displayed in the *Local Repository* widget.

en	To update all packages:

en	Click on the *Update all installed packages* button in the left sidebar.

en	This feature reads the information of all defined package repositories and determines whether a new version for every installed package exsits in the repository. It calculates the correct order to update the packages respecting all other package dependencies, even if new versions of existing packages require new packages not yet installed in the system.

en	To update a package that was installed from a file, simply install the newer version as explained above. However, they may not be updated by the button in the sidebar.

en	Remove Packages

en	If you remove a package you also delete all data managed by that package.

en	If a certain package is no longer required, you may remove it. To uninstall a package follow these steps:

en	Select the package from the *Local Repository* widget.

en	Click on the *Uninstall* link in the *Action* column.

en	Follow the uninstall instructions.

en	Performance Log

en	Performance is always a crucial topic for web-based applications. Administrators need to have the possibility to see which activities use which time to execute over time to identify potential increases over time and take proper measures.

en	OTOBO supports this requirement with the performance log. The performance log can, when it is activated, log activities and display various activity types and their min/max/average response time and a number of requests for different time frames.

en	Use this screen to view the performance log of OTOBO. The log overview screen is available in the *Performance Log* module of the *Administration* group.

en	To be able to see performance log in OTOBO, you have to enable its setting first.

en	Enable Performance Log Support

en	If the performance log is enabled, OTOBO collects all the information about requests and responses in an overview table.

en	Performance Log Screen

en	Clicking on an entry will show the details.

en	Performance Log Details Screen

en	Session Management

en	Administrators of web-based applications need to have access to the information who's connected to the system and, if required, delete unwanted sessions.

en	OTOBO offers the session management to quickly get an overview of agent and customer sessions, unique agents and customers currently logged in and the ability to kill sessions with just a mouse click.

en	Use this screen to manage logged in user sessions in the system. The session management screen is available in the *Session Management* module of the *Administration* group.

en	Session Management Screen

en	Manage Sessions

en	To see a logged in user session:

en	Select a logged in user from the list of sessions.

en	Click on the token.

en	See the details.

en	Session Management Details Screen

en	To kill a session:

en	Click on the *Kill this session* link in the *Kill* column.

en	Session Kill Screen

en	Clicking the *Kill this session* link removes the session immediately without confirmation. The unsaved work of the user will be lost!

en	To kill all sessions:

en	Click on the *Kill all sessions* button in the left sidebar.

en	Clicking the *Kill all session* link removes all sessions immediately without confirmation. The unsaved work of the users will be lost!

en	If several users are logged in to the system, use the filter box to find a particular session by just typing the name to filter.

en	SQL Box

en	In a ticket system, it is usually possible to have statistics that show a summarized view of ticket information when needed. Sometimes, it is however required to access the database directly to have even more individual reports, allow external statistic tools to query information from the system or perform in-depth analysis of a ticket behavior.

en	Direct access to the database requires access to the command line which an administrator may not have. In addition to username and password for the command line access, which is not given by all organizations, the username and password for the database are needed. These hurdles can prevent an administrator from using the database for more complex searches and operations.

en	OTOBO offers application administrators the SQL Box in the GUI (graphical user interface). It allows read access to the database. All results can be seen in the GUI or exported to CSV/Excel files.

en	Use this screen to query SQL statements in the system. The SQL box screen is available in the *SQL Box* module of the *Administration* group.

en	SQL Box Screen

en	Query SQL statements

en	The SQL statements entered here are sent directly to the application database. By default, it is not possible to change the content of the tables, only ``SELECT`` queries are allowed.

en	It is possible to modify the application database via SQL box. To do this, you have to enabled the system configuration setting ``AdminSelectBox::AllowDatabaseModification``. Activate it to your own risk!

en	To execute an SQL statement:

en	Enter the SQL statement into the SQL box.

en	Select the result format.

en	Click on the *Run Query* button.

en	SQL Box Widget

en	SQL Settings

en	SQL \*

en	The SQL statement to be queried.

en	Limit

en	Enter a number to limit the result to at most this number of rows. Leaving this field empty means there is no limit.

en	Don't use ``LIMIT`` inside the SQL statement. Always use this field to limit the number of results.

en	Result format

en	The format of the SQL statement result.

en	HTML

en	The results are visible below the SQL box in a new widget.

en	CSV

en	The results can be downloaded in comma separated plain text format.

en	Excel

en	The results can be downloaded as Microsoft Excel spreadsheet.

en	SQL Examples

en	To list some information about agents and output the results as HTML:

en	SQL Box Result

en	To list all tables, you need to leave empty the *Limit* field and run the following query:

en	To show the structure of the ``users`` table, you need to limit the results to 1 and run the following query (see the table header for the columns):

en	System Configuration

en	Modern systems have many ways to configure their behavior. Some use configuration files edited on the command line, and some use a graphical interface (and save the information to configuration files in the background), yet others use a database. Maintaining changes and auditing can sometimes be an issue, as it's not always clear who made a change. Making bulk changes is not always possible, and rolling back changes a chore.

en	OTOBO uses a comfortable graphical interface to configure the system. All changes to the default system configuration are stored in the database and can be audited (who changed a setting and when, what was the old and what is the new value) and rolled back to a previous state in case of misconfiguration.

en	Comfortable search allows finding the needed settings quickly and easily.

en	By using the `System Configuration History` package, you can easily roll back changes made by users. Contact sales@otobo.de to add this feature to your system. In one of the next OTOBO releases this feature is included in the standard framework.

en	Use this screen to manage the system configuration settings. OTOBO brings about 2200 configuration settings. The system configuration management screen is available in the *System Configuration* module of the *Administration* group.

en	Manage System Configurations

en	For security reasons, the configuration settings for the database connection cannot be changed in the graphical user interface of the system configuration. These have to be set manually in ``Kernel/Config.pm``.

en	To modify a system configuration, you need to do several steps. The following example shows you, how to find, modify, deploy and reset the system configuration ``FirstnameLastnameOrder``.

en	Find the system configuration by entering a search term ``lastname`` into to search box.

en	With the full-text search, all configuration settings can be scanned for one or more keywords. The full-text search not only searches through the names of the configuration settings, but also the descriptions and values. This allows an element to be found easily even if its name is unknown.

en	System Configuration - Search For Setting

en	Select the setting from the search results.

en	System Configuration - Setting Found

en	Click on the header of the widget to see the options.

en	System Configuration - Setting Expanded

en	Hover the mouse over the widget body to see the *Edit this setting* button.

en	System Configuration - Setting Hovered

en	Click on the *Edit this setting* button to activate the edit mode. In edit mode the widget gets a yellow border on the left.

en	If a setting is currently edited by an other administrator, it is not possible to get access to the edit mode for that setting until the other administrator finished his work.

en	System Configuration - Setting Clicked

en	Change the value of the setting. Editing can be cancelled by clicking the *Cancel* button on the right or hitting the *Escape* key on your keyboard. When editing is cancelled, all changes made during the current editing session are discarded.

en	System Configuration - Setting Modified

en	Click on the *Save* button. If the modification is saved, the widget gets a green border on the left.

en	System Configuration - Setting Saved

en	Go back and click on the *Deployment* button in the left sidebar. You are also notified in the notification bar, that you have undeployed settings.

en	System Configuration - Setting Changes

en	Review the changes.

en	You can click on the ⇄ button in the top right corner to compare the changes side-by-side.

en	System Configuration - Setting Different

en	Click on the *Deploy selected changes* button. If several settings are changed, it is possible to deploy only the selected settings.

en	Add a deployment comment, that explain for other administrators, what is changed and why. Use full sentence here.

en	System Configuration - Deploy Setting

en	Go back and search again the term ``lastname`` to find the modified setting. The widget has a gray border on the left to indicate, this setting is modified.

en	System Configuration - Setting Deployed

en	To reset the setting, click on the header of the widget to see the options. Then click on the *Reset setting* button.

en	System Configuration - Reset Setting

en	Click on the *Confirm* button.

en	Deploy the settings.

en	Using The Navigation Tree

en	Each configuration setting is classified by a category and a navigation group. Navigation groups are individual elements in the main navigation tree. By selecting one of these navigation entries, all settings assigned to the selected group will be shown. As long as no extensions are installed, the category selection is automatically hidden, but as soon as a package is installed which brings its own configuration settings (such as ITSM modules or Survey), the category selection will be revealed. Selecting a category makes the main navigation tree show only the navigation groups belonging to the selected category.

en	System Configuration Navigation Tree

en	To expand an element, click on the arrow next to it. The number between the parentheses indicates how many settings belongs to this element. If an element has no number, this element is only a wrapper category. It doesn't have settings, it has only sub-categories.

en	Using the navigation tree results the same as search for a setting. If you would like to see for a setting to which group belongs to, expand it by clicking on the header of the widget.

en	For example ``FirstnameLastnameOrder`` can be found in *Frontend* → *Base*.

en	Import And Export System Configurations

en	Click on the *Import & Export* button in the left sidebar to access the import-export screen.

en	System Configuration - Import and Export

en	To export the system configurations:

en	Click on the *Export current configuration* button in the *Export* widget.

en	Save the ``Export_Current_System_Configuration.yml`` file to your local file system.

en	Rename the file to a more descriptive name.

en	To import the system configurations:

en	Click on the *Browse…* button in the *Import* widget.

en	Click on the *Import system configuration* button.

en	System Log

en	Professional systems log their activities in one or more log files to help administrators when troubleshooting or to get an overview of what is going on in their system on a detailed level.

en	These logs are usually not available to application administrators without a certain level of permissions, and skills on the operating system.

en	OTOBO allows application administrators to access the system log comfortably by using the graphical interface without the need to have access to the server's command shell. The administrator can decide which level of logging is needed, to make sure that the log files are not unnecessarily filled.

en	Use this screen to view log entries of OTOBO. The log overview screen is available in the *System Log* module of the *Administration* group.

en	System Log Screen

en	Each line in the log contains a timestamp, the log priority, the system component and the log entry itself.

en	If several log entries are displayed in the log, use the filter box to find a particular log entry by just typing the name to filter.

en	System Log Configuration Options

en	``Core → Log``

en	System Maintenance

en	System maintenance is a crucial part of the work done by all system administrators. Some maintenance tasks require to put the operation on hold. In such cases, pro-active information to users is essential to raise their awareness and understanding.

en	OTOBO supports this with the *System Maintenance* module, which allows administrators (agents who have access to the group "admin") to schedule maintenance windows in advance and inform users with login messages and notifications about the planned maintenance. Also, during a scheduled maintenance window, only administrators are allowed to log into the system.

en	Use this screen to schedule system maintenance for the system. The system maintenance management screen is available in the *System Maintenance* module of the *Administration* group.

en	System Maintenance Management Screen

en	Manage System Maintenance

en	To schedule a system maintenance:

en	Click on the *Add New System Maintenance* button in the left sidebar.

en	Schedule New System Maintenance Screen

en	To edit a system maintenance:

en	Click on a system maintenance entry in the list of system maintenance entries or you are already redirected here from *Add New System Maintenance* screen.

en	Edit System Maintenance Information Screen

en	To delete a system maintenance:

en	Click on the trash icon in the last column of the overview table.

en	Delete System Maintenance Screen

en	If several system maintenance entries are added to the system, use the filter box to find a particular system maintenance by just typing the name to filter.

en	System Maintenance Settings

en	Select a date from when the system maintenance is scheduled.

en	Stop date

en	Select a date when the system maintenance is planned to finish.

en	The name of this resource. Any type of characters can be entered to this field including uppercase letters and spaces. The comment will be displayed in the overview table.

en	Login message

en	If this text is given, it will be displayed in the login screen, if the next option is checked.

en	There are some default system maintenance message set in the system configuration. For more information see the following system configuration settings:

en	``SystemMaintenance::IsActiveDefaultLoginErrorMessage``

en	``SystemMaintenance::IsActiveDefaultLoginMessage``

en	``SystemMaintenance::IsActiveDefaultNotification``

en	Show login message

en	If checked, the login message is displayed in the login screen of OTOBO.

en	Notify message

en	If this text is given, a notification will be displayed in the agent interface before the start of the system maintenance.

en	Set the minutes a notification is shown for notice about upcoming system maintenance period in system configuration setting:

en	``SystemMaintenance::TimeNotifyUpcomingMaintenance``

en	This widget gives an overview about the currently logged in users. It is possible to kill each sessions by clicking on the *Kill this session* links. You can also kill all sessions except yours by clicking on the *Kill all Sessions, except for your own* button.

en	Edit System Maintenance - Manage Sessions

en	CustomTranslations

en	Item “Translations”

en	New or existing translations are managed and administered in the "Translations"

en	Widget Languages

en	Overview Module Translations

en	Language Dropdown

en	To select the working language (By default the language of the User in session is selected).

en	Actions - Languages

en	Add Translation

en	To add a new translation in the system.

en	Edit Translations

en	To modify an existing translation.

en	Deploy Translations

en	To display the translations in the system.

en	Buttons Translations

en	Active Translations

en	Table with all translations displayed.

en	Table Active Translations

en	Filter

en	To filter the translation table.

en	Filter Active Translations

en	Translation States

en	Possible translation statuses.

en	Widget States Translations

en	New translation: New translations pending to be deployed.

en	Editing Translation: Edited translations pending deployment.

en	Translation Marked for Deletion: Translations marked for deletion pending deployment.

en	Deployed Translation: Active translations that have already been deployed.

en	Display States Translations

en	Hint

en	This widget contains a short explanatory text about the module.

en	Widget Hint

en	Add translation screen

en	This function allows you to add a new translation to OTOBO and allows you to select each of the translatable data elements in the system.

en	Overview Add Translation

en	Actions

en	This widget contains the "Go to Overview" button to return to the main screen of the module.

en	Widget actions Add Translation

en	This widget contains a short explanatory text about the section the user is in.

en	Widget Hint Add Translation

en	Language

en	Informative label of the language where the translation will be created.

en	Object

en	Selectable options with element to translate: Dynamic field content, Dynamic field labels, General label, Priorities, Queue, Services, SLA, Templates, Ticket status, Ticket types.

en	Object field

en	Dynamic Field List

en	This field is displayed only when "Dynamic Field" is selected in the "Object" field. It contains the names of the dynamic fields.

en	Content

en	This text field contains the tags to translate.

en	Content Field

en	Translation

en	Text field or table depending on the selected option, where the translation is entered.

en	Translation Field

en	Button Save and Finish

en	To save the translation and finish.

en	Cancel button

en	To cancel the action.

en	Button - Save or Cancel

en	Selectable Options

en	Dynamic Field Contents

en	Displays all existing dynamic fields and a dropdown field with values to translate is chosen

en	Table for translation - Dynamic Field Content

en	Dynamic Field Labels

en	Displays all existing dynamic fields in the system and a field is chosen to translate the label

en	Table for translation - Dynamic Field Labels

en	General Label

en	Allows to translate any existing label in the system.

en	Fields for translation - General labes

en	Priorities

en	Allows to translate the existing priorities in the system.

en	Fields for translation - Priorities

en	Queues

en	Allows to translate all existing queues.

en	Fields for translation - Queues

en	Services

en	Allows translation of all services.

en	Fields for translation - Services

en	SLAs

en	Allows translation of all SLAs.

en	Fields for translation - SLAs

en	Templates

en	Allows you to translate templates.

en	Fields for translation - Templates

en	Tickets States

en	Allows translation of ticket statuses.

en	Fields for translation - Ticket States

en	Tickets Types

en	Allows translation of ticket types.

en	Fields for translation - Ticket Types

en	Edit Translation

en	This section allows you to edit the translations displayed in the module.

en	When entering the section to edit translations a new screen is displayed with the following elements:

en	Translations

en	Translation table with

en	List of translations for editing

en	Filter Content: Translation filtering field.

en	Content: content column with all the translated tags in the module.

en	Translation: input column with all translations displayed with the possibility to edit and add a new translation.

en	Deploy Translation

en	This function allows you to deploy translations, changing their status to deployed and adding them to the database or deleting them from the module when they are marked for deletion.

en	Table of displayed translations.

en	Import/Export Translations

en	This function allows you to import and/or export files with translations using templates for the different languages configured.

en	When going to the Import/Export module, a new section "Translations" is displayed, a table with the existing templates for importing files.

en	Add Template

en	When adding a new template, the new "Translations" option is displayed in the "Object" input.

en	Format

en	Allows you to choose the CSV file format.

en	Fields Add template.

en	Fields Step 2.

en	Plain text format is selected.

en	Checkbox

en	To indicate whether empty fields keep the current values.

en	In the third step the following new fields are displayed:

en	Column Separator

en	Allows you to choose the column separator between Colon (:), Comma(,), Period(.), Semicolon(;), Tabulator (TAB).

en	Field Column separator Step 3.

en	Charset

en	The default character encoding is unmodifiable and according to the previously selected language.

en	Field Charset Step 3.

en	Include Column Headers

en	Allows you to choose between yes/no if the option is whether the file should have the column headers in the file to be imported.

en	Field Include Column Headers Step 3.

en	Information mapping table.

en	Add Mapping Element

en	To add the sections or columns of the file.

en	Key

en	Source string: Text string to be translated. Translation English: Language in which the translation will be done.

en	Mapped information.

en	Search information.

en	Restrict export per search

en	allows you to choose whether you want to restrict the export by searching for specific options.

en	Export Untranslated strings of

en	allows you to choose the option from which the untranslated strings will be exported.

en	Field Export Untraslated.

en	Ticket Information (Translation)

en	Attributes of the ticket such as Queues and Services that are translated using the translation module will be visible in the selection tree views of the fields.

en	Services in English

en	List Services.

en	Services translated to Spanish in tree view

en	List Services translated to Spanish.

en	Queues in English

en	List Queues.

en	Queues translated to Spanish in tree view

en	List Queues translated to Spanish.

en	Communication & Notifications

en	Clear, complete, and transparent communication is key to ensuring that your organization offers outstanding service to your customers. Your organization would like to give your customers the most consistent service and ensure that your service is highly recognizable, every time. Your teams want to have an identity which instills a specific sense of security and familiarity.

en	OTOBO provides you with the tools to build teams, trust and security to better and uniformly serve your customer. With system addresses you can assign your inbound mails to certain teams and allow them all to use the same address without causing confusion by using team mailboxes via a mail client. Templates, automatic answers, and attachment management let you leverage central management of the most important communications. Many other tools are also available and covered in the sections below.

en	Admin Notification

en	Corporations may need to make general announcements to everyone or publish news to several groups of agents or individuals. Also, OTOBO administrator may need to contact with specific agents regarding an event.

en	OTOBO gives the administration the tool *Admin Notification* making sending announcements and news to the masses of users accurate and timely, to target group of people, simple. Administrators can send notifications based on a specific list of recipients, or a group of users inside OTOBO, with powerful text editor enhanced content.

en	Use this screen to send administrative messages to specific agents, group or role members. The message compose screen is available in the *Admin Notification* module of the *Communication & Notifications* group.

en	Create Administrative Message Screen

en	Administrative Message Settings

en	The following settings are available when composing an administrative message. The fields marked with an asterisk are mandatory.

en	From \*

en	This email address will be added into the *From* field of the message.

en	Send message to users

en	One or more :doc:`../users-groups-roles/agents` can be selected in this field, to whom the message will be sent.

en	Send message to group members

en	One or more :doc:`../users-groups-roles/groups` can be selected in this field, to whose members the message will be sent.

en	Group members need to have permission

en	With these radio buttons can be selected, if a group member needs read-only or read-write permissions to receive the message.

en	Send message to role members

en	One or more :doc:`../users-groups-roles/roles` can be selected in this field, to whose members the message will be sent.

en	Also send to customers in groups

en	Select this checkbox to send the message also for customers in groups.

en	This option is available only, if ``CustomerGroupSupport`` setting is enabled.

en	Subject \*

en	The subject of the messages.

en	Body \*

en	The body text of the message.

en	Appointment Notifications

en	Missing appointments can damage your image with a customer. Once there is an appointment assigned in the calendar, it’s normal to receive notification:

en	Upon a new or changed event

en	Upon cancellation of an event

en	Before the event, as a reminder

en	Notification relieves the agent the stress of mentally tracking appointments.

en	OTOBO appointment notifications satisfies this need. Here an administrator can easily set notifications with general rules, including trigger events and filters. Afterward, appointments fitting the bill notify the correct users at the correct time.

en	Use this screen to add appointment notifications to the system. In a fresh OTOBO installation an appointment reminder notification is already added by default. The appointment notification management screen is available in the *Appointment Notifications* module of the *Communication & Notifications* group.

en	Appointment Notification Management Screen

en	Manage Appointment Notifications

en	To add an appointment notification:

en	Click on the *Add Notification* button in the left sidebar.

en	Fill in the required fields as explained in :ref:`Appointment Notification Settings`.

en	To edit an appointment notification:

en	Click on an appointment notification in the list of appointment notifications.

en	Modify the fields as explained in :ref:`Appointment Notification Settings`.

en	To delete an appointment notification:

en	Click on the trash icon in the list of appointment notifications.

en	Delete Appointment Notification Screen

en	To export all appointment notifications:

en	Click on the *Export Notifications* button in the left sidebar.

en	Choose a location in your computer to save the ``Export_Notification.yml`` file.

en	To import appointment notifications:

en	Click on the *Overwrite existing notifications?* checkbox, if you would like to overwrite the existing notifications.

en	Click on the *Import Notification configuration* button.

en	Appointment Notification Settings

en	For an example, see the default appointment reminder notification which is included in a fresh OTOBO installation.

en	Basic Appointment Notification Settings

en	Appointment Notification Settings - Basic

en	Comment

en	Show in agent preferences

en	Define how the notification should be displayed in agent preferences. The following options are available:

en	No

en	The notification won't be displayed in agent preferences. The notification is sent to all appropriate agents by the defined method.

en	Yes

en	The notification will be displayed in agent preferences for selection. The agents may opt-in or opt-out.

en	Yes, but require at least one active notification method.

en	The notification will be displayed in agent preferences, but require at least one active notification method. This is annotated by an asterisk next to the name.

en	Personal Appointment Notification Settings

en	Agent preferences tooltip

en	This message will be shown on the agent preferences screen as a tooltip for this notification.

en	Appointment Events

en	Appointment Notification Settings - Events

en	Event \*

en	Here you can choose which events will trigger this notification. An additional appointment filter can be applied below to only send for appointments with certain criteria.

en	Possible events are:

en	``AppointmentCreate``

en	Executed after an appointment has been created.

en	``AppointmentUpdate``

en	Executed after an appointment has been updated.

en	``AppointmentDelete``

en	Executed after an appointment has been deleted.

en	``AppointmentNotification``

en	This is a special appointment event that will be executed by the OTOBO daemon in time. If an appointment contains a date/time value for notifications, as already described in this documentation, and such a notification date is reached, the OTOBO daemon will execute this kind of event for every related appointment separately.

en	``CalendarCreate``

en	Executed after a calendar has been created.

en	``CalendarUpdate``

en	Executed after a calendar has been updated.

en	Appointment Filter

en	Appointment Notification Settings - Appointment Filter

en	This widget can optionally be used to narrow the list of appointments by matching configured values:

en	Calendar

en	Select which calendar the related appointment needs to be part of.

en	Title

en	Filter for a part or complete title of the appointment.

en	Location

en	Filter for a part or complete location of the appointment.

en	Resource

en	Choose from a list of teams or resources assigned to the appointments.

en	Appointment Notification Recipients

en	Appointment Notification Settings - Recipients

en	Send to

en	Select which agents should receive the notifications. Possible values are:

en	Agent (resources), who are selected within the appointment

en	All agents with (at least) read permission for the appointment (calendar)

en	All agents with write permission for the appointment (calendar)

en	Send to these agents

en	One or more agents can be selected who should receive the notifications.

en	Send to all group members (agents only)

en	One or more groups can be selected whom agents should receive the notifications.

en	Send to all role members

en	One or more roles can be selected whom agents should receive the notifications.

en	Send on out of office

en	If this option is checked, the notification will be sent even if the agent is currently out of office.

en	Once per day

en	Notify users just once per day about a single appointment using a selected transport. If this is the first notification about an appointment, then the notification will be sent. If a notification was already sent before and this option is checked, the OTOBO daemon will check the time the last notification was sent. If there was no notification sent in the last 24 hours, the notification will be sent again.

en	Appointment Notification Methods

en	Appointment Notification Settings - Notification Methods

en	Enable this notification method

en	Enable or disable this notification method. A notification method can be email, web view or SMS.

en	Active by default in agent preferences

en	This is the default value for assigned recipient agents who didn't make a choice for this notification in their preferences yet. If the box is enabled, the notification will be sent to such agents.

en	Additional recipient email addresses

en	Additional recipients can be added here. Use comma or semicolon to separate the email addresses.

en	Article visible for customer

en	An article will be created if the notification is sent to the customer or an additional email address.

en	Email template

en	Select which email template should be used for the notification.

en	Additional email templates can be added by placing a ``.tt`` file into the folder ``<OTOBO_Home>/Kernel/Output/HTML/Templates/Standard/NotificationEvent/Email/``. See the existing email templates for an example.

en	Enable email security

en	Checking this option will encrypt the notification email.

en	To use this feature, :doc:`pgp-keys` or :doc:`s-mime-certificates` need to be enabled.

en	Email security level

en	If *Enable email security* is checked, then this setting is activated. The following options are available:

en	PGP sign only

en	Sign only the notification email with PGP key. If no PGP keys have been added to the system, this option is not visible.

en	PGP encrypt only

en	Encrypt only the notification email with PGP key. If no PGP keys have been added to the system, this option is not visible.

en	PGP sign and encrypt

en	Sign and encrypt the notification email with PGP key. If no PGP keys have been added to the system, this option is not visible.

en	SMIME sign only

en	Sign only the notification email with S/MIME certificate. If no S/MIME certificates have been added to the system, this option is not visible.

en	SMIME encrypt only

en	Encrypt only the notification email with S/MIME certificate. If no S/MIME certificates have been added to the system, this option is not visible.

en	SMIME sign and encrypt

en	Sign and encrypt the notification email with S/MIME certificate. If no S/MIME certificates have been added to the system, this option is not visible.

en	If signing key/certificate is missing

en	Select the method, that should be used if signing key or certificate is missing.

en	If encryption key/certificate is missing:

en	Select the method, that should be used if encryption key or certificate is missing.

en	Appointment Notification Text

en	Appointment Notification Settings - Notification Text

en	The main content of a notification can be added for each languages with localized subject and body text. It is also possible to define static text content mixed with OTOBO smart tags.

en	The localized subject for a specific language.

en	Text \*

en	The localized body text for a specific language.

en	Add new notification language

en	Select which languages should be added to create localized notifications. The language of the customer or agent will be used as found in the customer and agent preferences. Secondarily, the system default language will be chosen. The fall back will always be English.

en	Deleting a language in ``DefaultUsedLanguages`` setting that already has a notification text here will make the notification text unusable. If a language is not present or enabled on the system, the corresponding notification text could be deleted if it is not needed anymore.

en	Appointment Notification Variables

en	Using variables in the text makes it possible to personalize messages. Variables, known as OTOBO tags, are replaced by OTOBO when generating the message. Find a list of available tags stems for this resource at the bottom of both add and edit screens.

en	For example, the variable ``<OTOBO_APPOINTMENT_TITLE[20]>`` expands to the first 20 characters of the title allowing a template to include something like the following.

en	This tag expands, for example to:

en	Communication Log

en	Managers, leaders, team leads, and system administrators may need to track past communication to follow up specific messages. In some cases, issues arise, and a target recipient did not receive a message. Without access to the mail server logs, tracking the communication is difficult.

en	OTOBO introduces the *Communication Log* module. It’s designed to track the communication: building and spooling the mail and the connection between client and server.

en	Use this screen to inspect the internal logs about communication handling. The communication log overview screen is available in the *Communication Log* module of the *Communication & Notifications* group.

en	Communication Log Overview Screen

en	Communication Log Overview

en	The communication log overview page is a dashboard-like screen with several metrics indicating the overall health of the system, depending on filtered communications.

en	Account Status Screen

en	Account status

en	This widget will signal if you have any issues with configured accounts used for fetching or sending messages.

en	Communication status

en	This widget will notify you if there are any errors with either account connections or message processing.

en	Communication state

en	This widget will display if there are any active communications currently in the system.

en	Average processing time

en	This is a cumulative time statistic that is needed to complete a communication.

en	You can select the time range in the left sidebar in order to filter communications depending on their creation time. In addition to this, you can also dynamically filter for any keywords, state of the communication, and you can sort the overview table by all columns.

en	If you click on a communication row in any table, you will be presented with a detailed view screen.

en	Communication Log Detailed View Screen

en	Every communication can contain one or more logs, which can be of *Connection* or *Message* type.

en	Connection

en	This type of logs will contain any log messages coming from the modules responsible for connecting to your accounts and fetching/receiving messages.

en	Message

en	This type of logs will contain any log messages related to specific message processing. Any module working on message themselves can log their actions in this log, giving you a clear overview of what's going on.

en	You can filter log entries based on their priority, by choosing desired priority in the left sidebar. Log level rules apply: by selecting a specific priority, you will get log entries that have that priority set and higher, with *Error* being the highest.

en	Email Addresses

en	The main channel of communication with the customers is often email. An organization consists of multiple departments or teams. Email addresses differ for each group which is servicing your customers. You may have the following:

en	``support@example.org``

en	``hr@exapmle.org``

en	``sales@example.org``

en	These addresses are just some examples, and you may have many more. Use these channels to receive and send messages, and in mail clients, one can often send with the wrong address.

en	OTOBO manages as many email addresses for your teams as needed. All your email addresses, whether for sending or receiving, are kept and configured nicely in one place. In the :ref:`queue settings`, the correct address is always chosen preventing that someone working in multiple roles sends an email out with the wrong account.

en	To enable OTOBO to send emails, you need a valid email address to be used by the system. OTOBO is capable of working with multiple email addresses, since many support installations need to use more than one. A queue can be linked to many email addresses, and vice versa. The address used for outgoing messages from a queue can be set when the queue is created.

en	Use this screen to add system email addresses to the system. An email address is already added to the system at installation time of OTOBO. The email address management screen is available in the *Email Addresses* module of the *Communication & Notifications* group.

en	Email Address Management Screen

en	Manage Email Addresses

en	To add an email address:

en	Click on the *Add System Address* button in the left sidebar.

en	Email Address Add Screen

en	Email addresses can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	Once an email address is added and set to valid, OTOBO cannot send an email to this address. This prevents loopbacks which could crash your system. If you need to transfer information between departments please use the ticket split option in the article menu. This will allow you to create a new ticket to another team for assigning a task, for example.

en	Article Menu

en	To edit an email address:

en	Click on an email address in the list of email addresses.

en	Email Address Edit Screen

en	If several email addresses are added to the system, use the filter box to find a particular email address by just typing the name to filter.

en	Email Address Settings

en	Email address \*

en	The email address to be added.

en	Display name \*

en	The name of this resource. Any type of characters can be entered to this field including uppercase letters and spaces. The name will be displayed in the sender information of the article.

en	Sender information

en	Sender Information

en	Queue \*

en	The queue, to which the email address will be added as default email address.

en	This setting will apply if the email is distributed via the recipient address. This setting can be overridden by :doc:`postmaster-filters` or in the :ref:`Mail Account Settings` when *Dispatching by selected Queue* is chosen.

en	An email address can only be set to *invalid* or *invalid-temporarily*, if it is not assigned to any queue.

en	PGP Keys

en	Secure communications protect your customers and you. In the GDPR encryption is explicitly mentioned as one of the security and personal data protection measures in a few articles. Although under the GDPR encryption is not mandatory, it is indeed essential in some areas.

en	OTOBO empowers you to encrypt communications where needed by means of :doc:`s-mime-certificates` or :doc:`pgp-keys`.

en	Setup of services and software required for encryption are not covered here because of independence to this software.

en	Use this screen to add PGP keys to the system. The PGP management screen is available in the *PGP Keys* module of the *Communication & Notifications* group.

en	PGP Management Screen

en	Manage PGP Keys

en	To be able to use PGP keys in OTOBO, you have to activate its setting first.

en	Enable PGP Support

en	To add a PGP key:

en	Click on the *Add PGP Key* button in the left sidebar.

en	Click on *Browse…* button to open the file dialog.

en	Select a PGP key from the file system.

en	Click on the *Add* button.

en	Add PGP Key Screen

en	To delete a PGP key:

en	Click on the trash icon in the list of PGP keys.

en	Delete PGP Key Screen

en	If several PGP keys are added to the system, use the search box to find a particular PGP key.

en	PGP Configuration Options

en	``Core → Crypt → PGP``

en	Postmaster Filters

en	Pre-sorting standard mail done in a mail room takes care that not every piece of mail sent to the office goes to the same group of people. After a second look at the envelope, rerouting occurs where needed.

en	OTOBO uses so-called *postmaster filters* to read the emails envelope and take further action. Depending upon, for example, a subject or sender, an email bound for the service desk could land in a sub-queue or be redirected to a completely different team to create transparency and give your customer the fastest service possible.

en	Use this screen to add postmaster filters to the system. The postmaster filter management screen is available in the *PostMaster Filters* module of the *Communication & Notifications* group.

en	Postmaster Filter Management Screen

en	Manage Postmaster Filters

en	When adding or editing a postmaster filter, please keep in mind that they are evaluated in *ASCIIbetical* order by name.

en	To add a postmaster filter:

en	Click on the *Add PostMaster Filter* button in the left sidebar.

en	To edit a postmaster filter:

en	Click on a postmaster filter in the list of postmaster filters.

en	To delete a postmaster filter:

en	Click on the trash icon in the list of postmaster filters.

en	Delete Postmaster Filter Screen

en	If several postmaster filters are added to the system, a filter box is useful to find a particular postmaster filter by just typing to filter.

en	Postmaster Filter Settings

en	Postmaster Filter Settings Example

en	Basic Postmaster Filter Settings

en	Postmaster Filter Settings - Basic

en	When adding or editing one of the postmaster filters, remember multiple filters may apply to a single mail. Rules are executed and sorted by the ASCII value of the names. Based on the sorted order in the overview, they are applied from top to bottom. Look at the `ASCII table <https://en.wikipedia.org/wiki/Ascii>`__ to see how to sort your names based on the *ASCIIbetical* order.

en	Stop after match \*

en	Postmaster filters are evaluated in *ASCIIbetical* order. This setting defines the evaluation of the subsequent postmaster filters.

en	All postmaster filters are executed.

en	The current postmaster filter is still evaluated, but evaluation of the remaining filters is canceled.

en	Filter Condition

en	Postmaster Filter Settings - Filter Condition

en	A postmaster filter consists of one or more conditions that must be met in order for the defined actions to be executed on the email. Filter conditions can be defined for specific mail header entries or for strings in the mail body.

en	Search header field … for value

en	Select a mail header or an ``X-OTOBO`` header from the first drop-down list, and enter a value as search term for the selected mail header to the second field. Even regular expressions can be used for extended pattern matching.

en	A list of mail header entries can be found in `RFC5322 <https://tools.ietf.org/html/rfc5322>`_. It is also possible to define ``X-OTOBO`` headers as filter condition. The different ``X-OTOBO`` headers and their meaning are the following:

en	``X-OTOBO-AttachmentCount``

en	This contains as value the number of attachments which are contained in the email (e.g. *0* for mails without attachments).

en	``X-OTOBO-AttachmentExists``

en	Depending on whether attachments are included in the email this ``X-OTOBO`` header is set to ``yes``, or it has a ``no`` value if no attachments are included.

en	``X-OTOBO-BodyDecrypted``

en	If the incoming mail was encrypted, it is possible to add a search term to look for the body of the incoming encrypted mail.

en	``X-OTOBO-CustomerNo``

en	Set the customer ID for the ticket.

en	``X-OTOBO-CustomerUser``

en	Set the customer user for the ticket.

en	``X-OTOBO-DynamicField-<DynamicFieldName>``

en	Saves an additional information value for the ticket on *<DynamicFieldName>* dynamic field. The possible values depend on dynamic field configuration (e.g. text: *Notebook*, date: *2010-11-20 00:00:00*, integer: *1*).

en	``X-OTOBO-FollowUp-*``

en	These headers are the same as the ones without the ``FollowUp`` prefix, but these headers are applied only for follow-up mails.

en	``X-OTOBO-FollowUp-State-Keep``

en	If set to *1*, the incoming follow-up message will not change the ticket state. For this purpose the header can be customized in the system configuration using option ``KeepStateHeader``.

en	``X-OTOBO-Ignore``

en	If set to ``Yes`` or ``True``, the incoming message will completely be ignored and never delivered to the system.

en	``X-OTOBO-IsVisibleForCustomer``

en	Controls if the article is shown to customer users. Possible values are *0* or *1*.

en	``X-OTOBO-Lock``

en	Set the lock state of a ticket. Possible values are ``locked`` or ``unlocked``.

en	``X-OTOBO-Loop``

en	If set to ``Yes`` or ``True``, no auto answer is delivered to the sender of the message (mail loop protection).

en	``X-OTOBO-Owner``

en	Set the agent as owner for the ticket.

en	``X-OTOBO-OwnerID``

en	Set the agent ID as owner for the ticket.

en	``X-OTOBO-Priority``

en	Set the priority for the ticket.

en	``X-OTOBO-Queue``

en	Set the queue where the ticket shall be sorted. If this is set, all other filter rules that try to sort a ticket into a specific queue are ignored. If you use a sub-queue, specify it as *Parent::Sub*.

en	``X-OTOBO-Responsible``

en	Set the agent as responsible for the ticket.

en	``X-OTOBO-ResponsibleID``

en	Set the agent ID as responsible for the ticket.

en	``X-OTOBO-SenderType``

en	Set the sender type for the ticket. Possible values are ``agent``, ``system`` or ``customer``.

en	``X-OTOBO-Service``

en	Set the service for the ticket. If you use a sub-service, specify it as *Parent::Sub*.

en	``X-OTOBO-SLA``

en	Set the service level agreement for the ticket.

en	``X-OTOBO-State``

en	Set the state for the ticket.

en	``X-OTOBO-State-PendingTime``

en	Set the pending time for the ticket (you should sent a pending state via ``X-OTOBO-State``). You can specify absolute dates like *2010-11-20 00:00:00* or relative dates, based on the arrival time of the email. Use the form ``+ $Number $Unit``, where ``$Unit`` can be *s* (seconds), *m* (minutes), *h* (hours) or *d* (days). Only one unit can be specified. Examples of valid settings: *+50s* (pending in 50 seconds), *+30m* (30 minutes), *+12d* (12 days).

en	Settings like *+1d 12h* are not possible. You can specify *+36h* instead.

en	``X-OTOBO-Title``

en	Set the title for the ticket.

en	``X-OTOBO-Type``

en	Set the type for the ticket.

en	These headers must be manually injected into the mail by means not provided for by OTOBO. OTOBO only accepts ``X-OTOBO`` headers from trusted sources.

en	The :ref:`Mail Account Settings` defines the trust level.

en	Negate

en	If checked, the condition will use the negate search term.

en	Set Email Headers

en	Postmaster Filter Settings - Set Email Headers

en	In this section you can choose the actions that are triggered if the filter rules match.

en	Set email header … with value

en	Select an ``X-OTOBO`` header from the first drop-down list, and add a value to the second field that should be set as value of the selected ``X-OTOBO`` header.

en	The ``X-OTOBO`` headers are already described above.

en	PostMaster Mail Accounts

en	Just as a company doesn't just have one department which receives traditional mail, your service desk will also serve multiple teams. Each team can have its physical email mailbox.

en	OTOBO eases setup for email mailboxes. OTOBO manages polling one or multiple email mailboxes of any internet standard type.

en	Use this screen to add mail accounts to the system. The mail account management screen is available in the *PostMaster Mail Accounts* module of the *Communication & Notifications* group.

en	Mail Account Management Screen

en	When fetching mail, OTOBO deletes the mail from the POP or IMAP server. There is no option to also keep a copy on the server. If you want to retain a copy on the server, you should create forwarding rules on your mail server. Please consult your mail server documentation for details.

en	If you choose IMAP, you can specify a folder for collection. Selective dispatching of mails is then possible.

en	All data for the mail accounts are saved in the OTOBO database. The ``bin/otobo.Console.pl Maint::PostMaster::MailAccountFetch`` command uses the settings in the database and fetches the mail. You can execute it manually to check if all your mail settings are working properly.

en	On a default installation, the mail is fetched every 10 minutes when the OTOBO daemon is running.

en	Manage Mail Accounts

en	To add a mail account:

en	Click on the *Add Mail Account* button in the left sidebar.

en	Add Mail Account Screen

en	To edit a mail account:

en	Click on a mail account in the list of mail accounts.

en	Edit Mail Account Screen

en	To delete a mail account:

en	Click on the trash icon in the list of mail accounts.

en	Delete Mail Account Screen

en	If several mail accounts are added to the system, a filter box is useful to find a particular mail account by just typing to filter.

en	Mail Account Settings

en	Type \*

en	There are different kind of protocols that are used for fetching mail. The following protocols are supported:

en	IMAP

en	IMAPS

en	IMAPTLS

en	POP3

en	POP3S

en	POP3TLS

en	Username \*

en	The username of the mail account.

en	Password \*

en	The password of the mail account.

en	Host \*

en	The host name of the mail account. Specify how the current article subject should be dealt with. The following methods are available:

en	IMAP Folder

en	The folder in the mail account to be fetched. Other folders remain untouched.

en	Trusted \*

en	If *Yes* is selected, any ``X-OTOBO`` headers attached to an incoming message are evaluated and executed. Because the ``X-OTOBO`` header can execute some actions in the ticket system, you should set this option to *Yes* only for known senders.

en	The ``X-OTOBO`` headers are explained in the filter conditions of :doc:`postmaster-filters`.

en	Dispatching \*

en	The distribution of incoming messages can be controlled if they need to be sorted by queue or by the content of the *To:* field.

en	Dispatching by email To: field

en	The system checks if a queue is linked with the address in the *To:* field of the incoming mail. You can link an address to a queue in the :doc:`email-addresses` screen. If the address in the *To:* field is linked with a queue, the new message will be sorted into the linked queue. If no link is found between the address in the *To:* field and any queue, then the message flows into the *Raw* queue in the system, which is the postmaster default queue after a default installation.

en	The postmaster default queue can be changed in system configuration setting ``PostmasterDefaultQueue``.

en	Dispatching by selected Queue

en	All incoming messages will be sorted into the specified queue. The address where the mail was sent to is disregarded in this case.

en	POP3 and IMAP OAuth2 Authentification

en	Authentication via OAuth2 / OpenID Connect is possible by using an additional package in OTOBO.

en	Please install the package **MailAccount-OAuth2** in the OTOBO package management.

en	After installing the package sometimes a restart of the OTOBO webserver or container is needed.

en	Azure Configuration

en	Go to https://portal.azure.com

en	**In the next step switch to ``Azure Active Directory`` and add a new ``Enterprise Application``:**

en	OAuth2 Azure Configuration

en	**Create your own application**

en	**Assign a name to the app**

en	**The mailbox user must be assigned to the application. You will need the Application ID lateron in OTOBO (Attention, the application ID of the "Enterprise APP" may differ from that of the "Application Registration". In this case, please use the Application/Client ID of the registration.).**

en	**You will also need the domain's tenant ID**

en	**In the next step you have to add a new app in App registration.**

en	**Create a Redirect URL of type Web and a secret client key.**

en	Redirect URL = https://<OTOBO address>/otobo/index.pl?Action=AdminMailAccount

en	Please add a new client secret and note the value (not the secret id) as we need it later. It will only appear during the creation and you will not be able to see it afterwards anymore. Apparently Microsoft only allows a time of validity for two years max.

en	**Switch to ``API permissions`` and add ``IMAP.AccessAsUser.All`` and ``POP.AccessAsUser.All``**

en	Please click on "Add permission" and choose Microsoft Graph, then new delegated permissions in the bar on the right. If Microsoft Graph is no show up as like in the screenshot.

en	**The Azure configuration is now complete. Please check whether port 143 and 993 are enabled.**

en	OTOBO OAuth2 Configuration

en	Please switch to the ``OTOBO Admin Interface -> System Configuration`` now and enable the profile / option ``OAuth2::MailAccount::Profiles###Custom1``.

en	In the next step, add the ApplicationID/ClientID and the Client secret (You need the value, not the secret id):

en	In the option ``OAuth2::MailAccount::Providers###MicrosoftAzure``, please adjust the provider. For ``AuthURL`` and ``TokenURL``, the path **"common"** must be replaced by the TenantID.

en	Now the desired profile can be selected under Admin -> PostMaster Mail Account.

en	When you save your settings, you will be redirected to the Active Directory login. If everything works as it is supposed to, you are redirected to the mail account overview after logging in and there is the corresponding mailbox. Of course, it says IMAPOAuth2 and not IMAPS.

en	it is important that you log in with the account that owns the mailbox. Otherwise errors can occur. Sometimes it is helpful to use a private tab for this.

en	You can check on the console if fetching mails from the newly created account is successful:

en	Or for a Docker installation:

en	Add ``--debug`` for more verbosity

en	S/MIME Certificates

en	Faculty and staff have key roles safeguarding critical information by implementing information security policies, standards, and controls. Safe email communication is a vital part of protecting this communication.

en	Use this screen to add S/MIME certificates to the system. The S/MIME management screen is available in the *S/MIME Certificates* module of the *Communication & Notifications* group.

en	S/MIME Management Screen

en	Manage S/MIME Certificates

en	To be able to use S/MIME certificates in OTOBO, you have to activate its setting first.

en	Enable S/MIME Support

en	To add an S/MIME certificate:

en	Click on the *Add Certificate* button in the left sidebar.

en	Select an S/MIME certificate from the file system.

en	Add S/MIME Certificate Screen

en	Only non binary keys contain ASCII (Base64) armored data started with a ``----- BEGIN CERTIFICATE -----`` line can be uploaded which are most commonly ``key.pem`` or ``root.crt``. Conversion of other formats like ``cert.p7b`` must be done using OpenSSL.

en	To add a private key:

en	Click on the *Add Private Key* button in the left sidebar.

en	Select a private key from the file system.

en	Add S/MIME Private Key Screen

en	To delete an S/MIME certificate:

en	Click on the trash icon in the list of S/MIME certificates.

en	Delete S/MIME Certificate Screen

en	If several S/MIME certificates are added to the system, use the filter box to find a particular S/MIME certificate by just typing the name to filter.

en	S/MIME Configuration Options

en	``Core → Crypt → SMIME``

en	Ticket Notifications

en	Streamlining communication can save hours of labor and prevent mistakes. Sending certain messages at pre-defined stages of communication not only keeps the customer and agents informed about specific events, but it can also aid your agents by programmatically doing automated updates to the customer.

en	The flexible OTOBO is an industry leader in email communication and offers you complete control of notifications based on any event in your system.

en	Use this screen to add ticket notifications to the system. In a fresh OTOBO installation several ticket notifications are already added by default. The ticket notification management screen is available in the *Ticket Notifications* module of the *Communication & Notifications* group.

en	Ticket Notification Management Screen

en	Manage Ticket Notifications

en	To add a ticket notification:

en	Fill in the required fields as explained in :ref:`Ticket Notification Settings`.

en	To edit a ticket notification:

en	Click on a ticket notification in the list of ticket notifications.

en	Modify the fields as explained in :ref:`Ticket Notification Settings`.

en	To delete a ticket notification:

en	Click on the trash icon in the list of ticket notifications.

en	Delete Ticket Notification Screen

en	To export all ticket notifications:

en	Certain settings are exported as numeric IDs and will break when importing to a system where these settings do not appear or reference other named items.

en	To import ticket notifications:

en	Ticket Notification Settings

en	For an example, see a default ticket notification which is included in a fresh OTOBO installation.

en	Basic Ticket Notification Settings

en	Ticket Notification Settings - Basic

en	Personal Ticket Notification Settings

en	Events

en	Ticket Notification Settings - Events

en	Event

en	Here you can choose which events will trigger this notification. An additional ticket filter can be applied below to only send for tickets with certain criteria.

en	Ticket Filter [1]_

en	Ticket Notification Settings - Ticket Filter

en	This widget can optionally be used to narrow the list of tickets by matching configured values:

en	The values in this list can grow as your system grows. The more :doc:`../processes-automation/dynamic-fields` are and features you have in your system, the longer the list will be.

en	State

en	Filter for a state of the ticket.

en	Priority

en	Filter for a priority of the ticket.

en	Queue

en	Filter for a queue in which the ticket is located.

en	Lock

en	Filter for a lock state of the ticket.

en	Customer ID

en	Filter for a customer ID of the ticket.

en	Customer User ID

en	Filter for a customer user ID of the ticket.

en	Dynamic Fields

en	Filter for some dynamic fields added to the system. For the complete list of dynamic fields see the :doc:`../processes-automation/dynamic-fields` chapter.

en	Article Filter [1]_

en	Ticket Notification Settings - Article Filter

en	This widget works only if ``ArticleCreate`` or ``ArticleSend`` is selected in the *Events* widget.

en	Article sender type

en	Filter for the sender type of the ticket. Possible values are *agent*, *system* or *customer*.

en	Customer visibility

en	Filter for the customer visibility. Possible values are *Invisible to customer* or *Visible to customer*.

en	Communication channel

en	Filter for the communication channel. Possible values are *Chat*, *Email*, *OTOBO*, *Phone* or *SMS*.

en	Include attachments to notification

en	If *Yes* is selected, attachments will be included to notification. Selecting *No* will not use this feature.

en	Attachment Name

en	Filter for attachment name.

en	Bcc

en	Filter for blind carbon copy field.

en	Body

en	Filter for body text.

en	Cc

en	Filter for carbon copy field.

en	From

en	Filter for the sender field.

en	Subject

en	Filter for the subject field.

en	To

en	Filter for the main recipients field.

en	SMS phone number

en	Filter for an SMS phone number.

en	SMS text

en	Filter for the SMS text.

en	SMS transaction number

en	Filter for an SMS transaction number.

en	Ticket Notification Recipients

en	Ticket Notification Settings - Recipients

en	Agent who created the ticket

en	Agent who is responsible for the ticket

en	Agent who owns the ticket

en	All agents subscribed to both the ticket's queue and service

en	All agents subscribed to the ticket's queue

en	All agents subscribed to the ticket's service

en	All agents watching the ticket

en	All agents with write permission for the ticket

en	All recipients of the first article

en	All recipients of the last article

en	Customer user of the ticket

en	Notify users just once per day about a single ticket using a selected transport. If this is the first notification about a ticket, then the notification will be sent. If a notification was already sent before and this option is checked, the OTOBO daemon will check the time the last notification was sent. If there was no notification sent in the last 24 hours, the notification will be sent again.

en	Capability to Send Ticket Notifications Only During Working Hours

en	A new option has been added to the ticket notification settings. Now, within the recipient's section, an additional field named "Calendar" is displayed.

en	Recipient block configuration

en	This field allows for the selection of whether notifications should be sent to recipients during working hours or outside of them:

en	Selecting the option for working hours will result in notifications being sent only during the established work schedule.

en	Option working hours

en	Conversely, choosing the non-working hours option will result in notifications being sent outside of the defined working hours.

en	Option outside working hours

en	Ticket Notification Methods

en	Ticket Notification Settings - Notification Methods

en	Notification Text

en	Ticket Notification Settings - Notification Text

en	Ticket Notification Variables

en	For example, the variable ``<OTOBO_TICKET_TicketNumber>`` expands to the ticket number allowing a template to include something like the following.

en	Use of regular expressions as a filter do not work here.

en	Introduction

en	OTOBO is an open source ticket request system with many features to manage customer telephone calls and emails. It is distributed under the GNU General Public License (GPL) and tested on various Linux platforms. Do you receive many emails and want to answer them with a team of agents?

en	About This Manual

en	This manual is intended for use by OTOBO administrators. The chapters describe the administration of the OTOBO software. The administrator interface is available in the *Admin* menu item of the main menu, when you logged in as an administrator. Administrators are users, who are member of the *admin* group.

en	Administrator Interface

en	The administrator interface contains several modules collected into groups. Use the filter box in the left sidebar to find a particular module by just typing the name to filter.

en	This manual shows the configuration possibilities needed to solve common problems. The chapters:

en	Identify a typical use-case for the administrator, to aid in orientation, and explain **what** OTOBO does to provide a solution (**warranty**).

en	Direct you **how** to configure OTOBO to fit your use-case (**utility**).

en	The chapters are the same as the modules in the administrator interface. The order of the chapters are also the same as they are displayed alphabetically in the (English) administrator interface. However, the steps to do to configure a fresh new OTOBO installation is different from this order. We recommend to configure OTOBO to do the steps as explained below.

en	Getting Started

en	The installation of OTOBO is explained in a separate `Installation Guide <https://doc.otobo.org/manual/installation/10.1/en/content/index.html>`__. To install OTOBO or upgrade OTOBO from a previous version, follow the steps described there.

en	After the installation of OTOBO is finished, you can login to the system with user ``root@localhost`` and using the generated password.

en	A fresh new OTOBO installation contains only the default settings. You need to customize your system to work properly and meet your needs.

en	First, you need to check some :doc:`administration/system-configuration` and modify the values, if needed. ``FQDN``, ``SystemID`` and ``SendmailModule`` are the most important. Defining ``TimeWorkingHours`` and ``TimeVacationDays`` are also needed to calculate the escalation times correctly in OTOBO.

en	Then, open the :doc:`communication-notifications/postmaster-mail-accounts` module to add email addresses used by the system. For sending email, you can add more :doc:`communication-notifications/email-addresses`.

en	To improve the security, :doc:`communication-notifications/pgp-keys` or :doc:`communication-notifications/s-mime-certificates` can be used for encryption of emails.

en	Let's continue with users, but you might need to add some :doc:`users-groups-roles/groups` and/or :doc:`users-groups-roles/roles` to the system first. It is recommended to create new groups for each main queues. There are some groups in your OTOBO, but no roles are defined by default. You can add roles, if needed, and you can set the :doc:`users-groups-roles/roles-groups` relations.

en	The next step is to add :doc:`users-groups-roles/agents` to the system and set the :doc:`users-groups-roles/agents-groups` and/or :doc:`users-groups-roles/agents-roles` relations.

en	Now you can add :doc:`users-groups-roles/customers` and :doc:`users-groups-roles/customer-users`. Customers are companies and customer users are the employees of the company.

en	Both agents and customer users can log in using Active Directory or LDAP for authentication. In these cases doesn't need to add users manually.

en	Like for agents, customers users can also assign to groups using the :doc:`users-groups-roles/customer-users-groups` management screen. Similarly, :doc:`users-groups-roles/customer-users-customers` relations can also be set.

en	Your OTOBO installation already contains a standard salutation and a standard signature, but you might need to edit them or create new :doc:`ticket-settings/salutations` and :doc:`ticket-settings/signatures`. Queues can not be created without salutations and signatures, and only one salutation and signature can be assigned to a queue.

en	After system addresses, salutations, signatures, groups are set, you can continue the setup with :doc:`ticket-settings/queues`. Each queue has to assign to a group, and only the group members can see the tickets in the assigned queue.

en	Now you can add :doc:`ticket-settings/auto-responses` and assign them to queues using the :doc:`ticket-settings/queues-auto-responses` management screen. Your OTOBO installation already contains some automatic responses, you can use or edit them instead of create new ones.

en	To reduce the time needed for answering the tickets, :doc:`ticket-settings/templates` can be created.

en	Normal templates can contain :doc:`ticket-settings/attachments`, and you can assign the uploaded attachments to templates using the :doc:`ticket-settings/templates-attachments` management screen.

en	When templates are created, you can set the templates to use in queues in the :doc:`ticket-settings/templates-queues` management screen.

en	You need to review the default :doc:`ticket-settings/priorities`, :doc:`ticket-settings/states` and :doc:`ticket-settings/types`, and add new elements, if needed.

en	The customer requests can be categorize into services. If you would like to use this possibility, then create some :doc:`ticket-settings/services` and set the :doc:`users-groups-roles/customer-users-services` relations. Furthermore, :doc:`ticket-settings/service-level-agreements` can be assign to the services.

en	Now you can add some notifications to be received by agents, if particular events occur. You can do this in the :doc:`communication-notifications/ticket-notifications` screen.

en	To help agents to organize appointments, you can setup the :doc:`administration/calendars` and the :doc:`communication-notifications/appointment-notifications`.

en	Tickets, articles and other objects in OTOBO can be extended with :doc:`processes-automation/dynamic-fields` or can be reduced with :doc:`processes-automation/access-control-lists`.

en	Without doing everything manually, the number of failure can be reduced. Automatize some process in OTOBO using :doc:`processes-automation/generic-agent` jobs or creating processes with :doc:`processes-automation/process-management`. The incoming emails can be pre-processed and dispatched automatically by defining some :doc:`communication-notifications/postmaster-filters`.

en	If external systems need to integrate with OTOBO, :doc:`processes-automation/web-services` will be very useful for this.

en	However OTOBO has many features by default, you can extend the functionality by installing packages with the :doc:`administration/package-manager`.

en	Become OTOBO Expert

en	The next chapters of this manual describe the features and configuration settings of OTOBO more detailed and give you a good overview of :doc:`administration/system-configuration`, that can be adjusted to modify the behavior of OTOBO.

en	OTOBO Team Services

en	This section describes the functionality of your OTOBO to support you OTOBO service partner. Regardless whether this is Rother OSS, an OTOBO Partner, or any other service provider of your choosing.

en	Support Data Collector

en	The Support Data Collector is used to collect characteristic data of your OTOBO installation. Use this screen to review the data and download it as a bundle.

en	Download Support Bundle Screen

en	To generate a support bundle:

en	Click on the *Generate Support Bundle* button in the left sidebar.

en	Send the bundle to your admin email address of download it as a `.tar.gz`.

en	Download Support Bundle Dialog

en	You may just unpack the bundle and inspect it's content. The bundle contains:

en	All information rendered on this site: ``SupportData.json``.

en	A list of all installed packages: ``InstalledPackages.csv``.

en	A list of all modified settings: ``ModifiedSettings.csv``.

en	A snapshot of all modified files in the system: ``application.tar.gz``.

en	Passwords are redacted in the generated bundle.

en	Collected Data

en	The screen contains several sections. Each section has some entries accompanied by a traffic light, that indicates the following:

en	Gray LED is *informational* only.

en	Green LED means that the values is within good range.

en	Yellow LED means notification, you have to check the value, but it is not an error.

en	Red LED means error, you have to do something to solve the issue.

en	Cloud Services

en	Rother OSS does not collect any data of your OTOBO. There are no cloud services you may register to at this point.

en	Processes & Automation

en	Working effectively with tickets requires more than just the possibility to manually change their state, add information, communicate with other persons and finally close the tickets.

en	Automation frees agents from reoccurring and time-consuming tasks and allows them to focus on activities, where their interaction is required.

en	Process management guides customer users and agents through ticket creation to closure ensuring that tickets take defined workflows at any time.

en	OTOBO offers many options to automate tasks based on events, time, external systems and defined processes. OTOBO also includes the possibility to add individual information types to tickets and help agents to lower their error rate when working with tickets by allowing only defined activities for tickets in specific states.

en	Access Control Lists (ACL)

en	Working with tickets can become a bewildering task. Many options are given to process, or close tickets, even if they are not needed in the current state of a ticket or due to the role of the current agent. Hiding unneeded entries cleans up the menu bar and gets it easier to work with, hiding values from dynamic fields or next queues lowers chance of human error.

en	OTOBO uses access control lists (ACL) to restrict agents and customer users on ticket options, allowing only correct and meaningful activities with a ticket. OTOBO administrators can easily generate ACLs in the graphical interface to prevent ticket closure until meeting specific requirements, prevent tickets from being moved to queues before adding the defined information and much more.

en	Use this screen to manage access control lists in the system. A fresh OTOBO installation contains no access control lists by default. The access control lists management screen is available in the *Access Control Lists (ACL)* module of the *Processes & Automation* group.

en	ACL Management Screen

en	Manage Access Control Lists

en	When creating some access control lists, please keep in mind that they are executed alphabetically as displayed in the access control lists overview.

en	ACL restrictions will be ignored for the superuser account (UserID 1).

en	To create a new ACL:

en	Click on the *Create New ACL* button in the left sidebar.

en	You will be redirected to *Edit ACL* screen to edit the ACL structure.

en	Create New ACL Screen

en	To edit an ACL:

en	Click on an ACL in the list of ACLs or you are already redirected here from *Create New ACL* screen.

en	Modify the fields and the ACL structure.

en	Deploy all ACLs.

en	Edit ACL Structure Screen

en	To delete an ACL:

en	Click on an ACL in the list of ACLs.

en	Set the *Validity* option to *invalid* or *invalid-temporarily*.

en	Click on the *Save* button. A new *Delete Invalid ACL* button will appear in the left sidebar.

en	Click on the *Delete Invalid ACL* button.

en	Click on the *Delete* button in the confirmation screen.

en	ACLs are written into ``ZZZACL.pm`` file in Perl format. Without deploying, all ACLs are still in this cache file even if they are deleted or the *Validity* option is set to *invalid* or *invalid-temporarily*. Don't forget to deploy all ACLs after modifications!

en	To deploy all ACLs:

en	Click on the *Deploy ACLs* button in the left sidebar.

en	New or modified ACLs have to deploy in order to make affect the behavior of the system. Setting the *Validity* option to *valid* just indicates, which ACLs should be deployed.

en	To export all ACLs:

en	Click on the *Export ACLs* button in the left sidebar.

en	Choose a location in your computer to save the ``Export_ACL.yml`` file.

en	To import ACLs:

en	Click on the *Overwrite existing ACLs?* checkbox, if you would like to overwrite the existing ACLs.

en	Click on the *Import ACL configuration(s)* button.

en	Deploy the imported ACLs with *Deploy ACLs* button.

en	If several ACLs are added to the system, use the filter box to find a particular ACL by just typing the name to filter.

en	Changing the name of this object should be done with care, the check only provides verification for certain settings and ignores things where the name can't be verified. Some examples are dashboard filters, action control lists (ACLs), and processes (sequence flow actions) to name a few. Documentation of your setup is key to surviving a name change.

en	ACL Settings

en	Description

en	Like comment, but longer text can be added here.

en	Stop after match

en	ACLs are evaluated in alphabetical order. This setting disables the evaluation of the subsequent ACLs.

en	Edit ACL Structure

en	The ACL definition can be split into two big parts, *Match settings* and *Change settings*. In the matching sections the ACLs contain attributes that has to be met in order to use the ACL. If the attributes defined in the ACL do not match with the attributes that are sent, then the ACL does not take any affect, but any other match ACL will. The change sections contain the rules to reduce the possible options for a ticket.

en	Match settings

en	``Properties``

en	This section contains matching options that can be changed on the fly. For example on a ticket creation time the data of the ticket changes dynamically as the agent sets the information. If an ACL is set to match a ticket attribute then only when the matching attribute is selected the ACL will be active and might reduce other ticket attributes, but as soon as another value is selected the ACL will not take any affect.

en	``PropertiesDatabase``

en	This section is similar to ``Properties`` but does not take changes in ticket attributes that are not saved into the database, this means that changing an attribute without submit will not make any effect. This section is not use for ticket creation screens (as tickets are not yet created in the database).

en	Change settings

en	``Possible``

en	This section is used to reset the data to be reduce to only the elements that are set in this section.

en	``PossibleAdd``

en	This section is used to add missing elements that were reduced in other ACLs. This section is only used in together with other ACLs that have ``Possible`` or ``PossibleNot`` sections.

en	``PossibleNot``

en	This section is used to remove specific elements from the current data. It could be used stand alone or together with other ACLs with a ``Possible`` or ``PossibleAdd`` sections.

en	Modifiers

en	In order to make the development of ACLs easier and more powerful there is a set of so called modifiers for the attributes on each section. This modifiers are explained below:

en	``[Not]``

en	This modifier is used to negate a value, for example ``[Not]2 low``. Talking about priorities will be the same as to have: *1 very low*, *3 normal*, *4 high*, *5 very high*.

en	``[RegExp]``

en	It is used to define a regular expression for matching several values, for example ``[RegExp]low``. In this case talking about priorities is the same as *1 very low*, *2 low*.

en	``[regexp]``

en	It is very similar to ``[RegExp]`` but it is case insensitive.

en	``[NotRegExp]``

en	Negated regular expressions, for example ``[NotRegExp]low``. Talking about priorities is the same as *3 normal*, *4 high*, *5 very high*.

en	``[Notregexp]``

en	It is very similar to ``[NotRegExp]`` but it is case insensitive.

en	ACL Examples

en	Move Ticket to Queue Based on Priority

en	This example shows you how to allow movement into a queue of only those tickets with ticket priority *5 very high*.

en	First, it needs to have a name. In this case, it is *100-Example-ACL*. Note that the ACLs will be numerically sorted before execution, so you should use the names carefully. The comment and the description fields are optional.

en	100-Example-ACL - Basic Settings

en	Secondly, you have a *Properties* section which is a filter for your tickets. All the criteria defined here will be applied to a ticket to determine if the ACL must be applied or not. In our example, a ticket will match if it is in the queue *Raw* and has priority *5 very high*. This is also affected by changes in the form (e. g. if the ticket is the queue *Raw* and had a priority *3 normal* at this moment the ACL will not match, but then priority drop-down is selected and the priority is changed now to *5 very high* then will also match).

en	100-Example-ACL - Match Settings

en	Lastly, a section *Possible* defines modifications to the screens. In this case, from the available queues, only the queue *Alert* can be selected in a ticket screen.

en	100-Example-ACL - Change Settings

en	Don't forget to set *Validity* to *valid* and deploy the newly created ACL.

en	Move Ticket to Queue Based on Priority Stored in Database

en	This example is very similar to the first one, but in this case only tickets in the queue *Raw* and with a priority *5 very high*, both stored in the database will match. This kind of ACLs does not consider changes in the form before the ticket is really updated in the database.

en	101-Example-ACL

en	Disable Ticket Close in Queue and Hide Close Button

en	This example shows how to disable the closing of tickets in the queue *Raw*, and hide the close button. It is possible to filter a ticket field (state) with more than one possible values to select from. It is also possible to limit the actions that can be executed for a certain ticket. In this case, the ticket cannot be closed.

en	102-Example-ACL

en	Remove State

en	This example shows how it is possible to define negative filters (the state *closed successful* will be removed). You can also see that not defining match properties for a ticket will match any ticket, i. e. the ACL will always be applied. This may be useful if you want to hide certain values by default, and only enable them in special circumstances (e. g. if the agent is in a specific group).

en	103-Example-ACL

en	Using Regular Expressions

en	This example shows you how you can use regular expressions for matching tickets and for filtering the available options. This ACL only shows *Hardware* services for tickets that are created in queues that start with *HW*.

en	104-Example-ACL

en	Disallow Process For Customer

en	This ACL restricts the process *P14* in the external interface using the customer ID *TheCustomerID*.

en	105-Example-ACL

en	Disallow Standard Reply Function For Customers in Process

en	This ACL prohibits using the reply button in CustomerTicketZoom if the ticket is a process ticket of the process with entity ID *Process-0123456789abcdef*.

en	106-Example-ACL

en	ACL Reference

en	Properties, keys and values that can be used in ACLs are highly dependent on the OTOBO installation. For example the possibilities can be extended by installing extension modules, as well as it can depend on the customer user mapping set in ``Config.pm``. Therefore it is not possible to provide a full ACL reference, that contains all settings.

en	For properties, keys and values that can be used in ACLs, see the following example ACL in YAML format.

en	Beside general information required for all tickets, organizations have individual needs to add specific details to tickets. This needed information takes various formats like texts, integers, date-time and more.

en	OTOBO supports adding a so-called :term:`dynamic field` to handle texts, integers, drop-down lists, multi-select fields, date-time, checkboxes and more. OTOBO administrators can define where those fields should be visible or editable, and of course, the dynamic fields are also available in statistics and reports.

en	Use this screen to manage dynamic fields in the system. A fresh OTOBO installation contains two dynamic fields by default. The dynamic field management screen is available in the *Dynamic Fields* module of the *Processes & Automation* group.

en	Dynamic Field Management Screen

en	Manage Dynamic Fields

en	To create a new dynamic field:

en	Choose an object type in the left actions sidebar and select a dynamic field type from its drop-down.

en	Create New Dynamic Field Screen

en	To edit a dynamic field:

en	Click on a dynamic field in the dynamic fields list.

en	Edit Dynamic Field Screen

en	To delete a dynamic field:

en	Delete Dynamic Field Screen

en	If several dynamic fields are added to the system, use the filter box to find a particular dynamic field by just typing the name to filter.

en	Dynamic Field Settings

en	General Dynamic Field Settings

en	These settings are the same for all types of dynamic fields.

en	Dynamic Field General Screen

en	The name of this resource. The value should be alphabetic and numeric characters only. The name will be displayed in the overview table.

en	Label \*

en	This is the name to be shown on the screens where the field is active.

en	It is possible to add translations for a dynamic field label. Label translations have to be added manually to language translation files.

en	Field order \*

en	This is the order in which this field will be shown on the screens where is active.

en	Field type

en	This type has been selected in the left sidebar and can not be changed here anymore. This is a read-only field.

en	Object type

en	The object type determines where the dynamic field can be used. For example a dynamic field with object type *Ticket* can be used only in tickets, and can not be used in articles.

en	The following settings are relevant only for the particular type of dynamic fields.

en	Checkbox Dynamic Field Settings

en	Checkbox dynamic field is used to store true or false value.

en	Default value \*

en	The default value for the checkbox.

en	Checked

en	The checkbox is checked by default.

en	Unchecked

en	The checkbox is unchecked by default.

en	Contact With Data Dynamic Field Settings

en	This dynamic field allows to add contacts with data to tickets.

en	Name Field \*

en	The attribute ``Name`` is always mandatory and it is not automatically added, so for each new data source this attribute must be added manually. Within the data source definition (or dynamic field configuration) this must be represented by the key ``Name`` and the value could be *Name* for example.

en	ValidID Field \*

en	The attribute ``ValidID`` is always mandatory and it is not automatically added, so for each new data source this attribute must be added manually. Within the data source definition (or dynamic field configuration) this must be represented by the key ``ValidID`` and the value could be *Validity* for example.

en	Other Fields

en	These are the possible data attributes for contacts. Clicking on the *⊞* button of the *Add Fields* will add two new fields, where a *Key* (internal value) and a *Value* (displayed value) can be set. With the button you can add multiple key-value pairs.

en	The keys ``Name`` and ``ValidID`` are already used by *Name Field* and *ValidID Field*. Do not use these keys again!

en	Add Fields

en	Use this button to add more fields to dynamic field.

en	Mandatory fields

en	Comma separated list of mandatory keys.

en	Keys ``Name`` and ``ValidID`` are always mandatory and doesn't have to be listed here.

en	Sorted fields

en	Comma separated list of keys in sort order. Keys listed here come first, all remaining fields afterwards and sorted alphabetically.

en	Searchable fields

en	Comma separated list of searchable keys.

en	Key ``Name`` is always searchable and doesn't have to be listed here.

en	Translatable values

en	If you activate this option the values will be translated to the user defined language.

en	You need to add the translations manually into the language translation files.

en	When the dynamic field was saved, click on the name of the newly created dynamic field in the overview table. The *Edit Dynamic Field* screen will open. There is a button *Add or edit contacts*, that points to *Tickets* → *Edit contacts with data* to add some data.

en	Contact With Data Management Screen

en	To add a new contact with data:

en	Select a dynamic field from the drop-down list in *Actions* widget of the left sidebar.

en	Click on the *Add contact with data* button in the left sidebar.

en	Add Contact With Data Screen

en	To edit a contact with data:

en	Click on a contact with data in the list of contact with data entries.

en	Edit Contact With Data Screen

en	The usage of this type of dynamic field is more complex then the others. An exemplary usage of contacts with data is as follows:

en	Create a new dynamic field of type contact with data.

en	Set the possible contact attributes (possible values).

en	Type *Name* into *Name Field*.

en	Type *Validity* into *ValidID Field*.

en	Add any other attribute with *Add Fields* button such as ``Telephone`` attribute (key: ``Telephone``, value: *Phone*).

en	Add the list of mandatory attribute keys comma separated (``Name`` and ``ValidID`` are not needed).

en	Set the attribute key order list comma separated as: ``Name,Telephone,ValidID``.

en	Add the list of searchable attribute keys comma separated (``Name`` is not needed).

en	Populate the data source by adding at least one contact in the newly created data source by using *Tickets* → *Edit contacts with data* screen from the main navigation bar.

en	Add the new dynamic field to the screen's configuration where it should be shown. For example in *New Phone Ticket* screen by updating the system configuration setting ``Ticket::Frontend::AgentTicketPhone###DynamicField`` and do the same for ``Ticket::Frontend::AgentTicketZoom###DynamicField``.

en	Go to *New Phone Ticket* screen, and notice that the new field is there. Add all needed information to the ticket.

en	Select an existing contact using autocomplete and choosing a contact.

en	The assigned contact and its attributes will be shown in the *Ticket Zoom* screen.

en	It is possible to update the attributes of the contact by clicking the *Edit contact data* button that appears in the right side of the title of the contact data box (if the current user is a member of the groups defined in system configuration setting ``Frontend::Module###AdminDynamicFieldContactWithData``).

en	If it's necessary to change the contact for this ticket, it can be done via any other ticket action where the dynamic field is configured for display.

en	Date Dynamic Field Settings

en	Date dynamic field is used to store a date value.

en	Default date difference

en	The difference from **now** (in seconds) to calculate the field default value (e.g. 3600 or -60).

en	Define years period

en	Activate this feature to define a fixed range of years (in the future and in the past) to be displayed on the year part of the field. If set to *Yes* the following options will be available:

en	Years in the past

en	Define the number of years in the past from the current day to display in the year selection for this dynamic field in edit screens.

en	Years in the future

en	Define the number of years in the future from the current day to display in the year selection for this dynamic field in edit screens.

en	Show link

en	Here you can specify an optional HTTP link for the field value in overviews and zoom screens. Example:

en	Link for preview

en	If filled in, this URL will be used for a preview which is shown when this link is hovered in ticket zoom. Please note that for this to work, the regular URL field above needs to be filled in, too.

en	Restrict entering of dates

en	Here you can restrict the entering of dates of tickets.

en	Prevent entry of dates in the future

en	Selecting this option will prevent entering a date that is after the current date.

en	Prevent entry of dates in the past

en	Selecting this option will prevent entering a date that is before the current date.

en	Date / Time Dynamic Field Settings

en	Date / time dynamic field is used to store a date time value.

en	The settings for this type of dynamic field is the same as for date dynamic field.

en	Dropdown Dynamic Field Settings

en	Drop-down dynamic field is used to store a single value, from a closed list.

en	Possible values

en	These are the possible data attributes for contacts. Clicking on the *⊞* button will add two new fields, where a key (internal value) and a value (displayed value) can be set. With the button you can add multiple key-value pairs.

en	Default value

en	This is the default value for this field and this will be shown on the edit screens.

en	Add empty value

en	If this option is activated an extra value is defined to show as a *-* in the list of possible values. This special value is empty internally.

en	Tree View

en	Activate this option to display values as a tree. In case you want to have a tree structure (expandable values), you have to implement the complete tree structure in the *key* (e.g. Country: ``Country::Germany`` and ``Country::France``) and only the lowest item in the *value* (e.g. Country: ``Germany`` and ``France``) of the *possible values*.

en	Multiselect Dynamic Field Settings

en	Text Dynamic Field Settings

en	Text dynamic field is used to store a single line string.

en	Check RegEx

en	Here you can specify a regular expression to check the value. The regex will be executed with the modifiers ``xms``. Example:

en	Add RegEx

en	Clicking on the *⊞* button will add two new fields, where a regular expression and an error message can be added.

en	Textarea Dynamic Field Settings

en	Textarea dynamic field is used to store a multiple line string.

en	Number of rows

en	The height (in lines) for this field in the edit mode.

en	Number of cols

en	The width (in characters) for this field in the edit mode.

en	Database Dynamic Field

en	This dynamic field is already included in OTOBO 10 Standard! The documentation on the field types still needs to be completed.

en	Web Service Dynamic Field

en	A Web Service dynamic field relies upon a working Web Service, more precisely on a Web Service invoker.

en	For this purpose, an invoker of type PassThrough can be used.

en	For the outgoing API call, DynamicFieldID, -Label, -Name and -Value, as well as UserID and Ticket and Form data are passed to the invoker.

en	For the dynamic field Web Service to work, the response data needs to be mapped into this structure:

en	This can be accomplished by implementing an XSLT mapping.

en	Display Dynamic Fields on Screens

en	To display a dynamic field on a screen:

en	Make sure that the dynamic field *Validity* is set to *valid*.

en	Open the *System Configuration* module in the admin interface.

en	Navigate to *Frontend* → *Agent* → *View* and select a view to add the dynamic field to.

en	Find the setting ends with ``###DynamicField`` and click on the *Edit this setting* button.

en	Click on the *+* button to add the dynamic field.

en	Enter the name of the dynamic field to the text box and click on the tick button.

en	Select *1 - Enabled* or *2 - Enabled and required*.

en	Click on the tick button on the right to save the setting.

en	Deploy the modified system configuration.

en	Display Dynamic Fields on Screen

en	It is possible to add multiple dynamic fields at the same time. To do this, repeat steps 5-7.

en	Set Default Value via Ticket Event Module

en	A ticket event (e.g. ``TicketCreate``) can trigger a value set for a certain field, if the field does not have a value yet.

en	Navigate to *Core* → *Event* → *Ticket* and search for the setting ``Ticket::EventModulePost###9600-TicketDynamicFieldDefault``.

en	Click on the *Edit this setting* button to activate the setting.

en	Activate Ticket Event Module

en	Example: activate *Field1* in ``TicketCreate`` event:

en	Navigate to *Core* → *Ticket* → *DynamicFieldDefault* and search for the setting ``Ticket::TicketDynamicFieldDefault###Element1``.

en	Activate Dynamic Field in Ticket Create Event

en	This configuration can be set in any of the 16 ``Ticket::TicketDynamicFieldDefault###Element`` settings.

en	If more than 16 fields needs to be set up, a custom XML file must be placed in ``$OTOBO_HOME/Kernel/Config/Files/XML`` directory to extend this feature.

en	Set Default Value via User Preferences

en	The dynamic field default value can be overwritten with a user defined value stored in the personal preferences.

en	Navigate to *Frontend* → *Agent* → *View* → *Preferences* and search for the setting ``PreferencesGroups###DynamicField``.

en	Activate Dynamic Field in Personal Preferences

en	Click on your avatar on the top left corner, and select *Personal Preferences* → *Miscellaneous* to add a default value for the dynamic field.

en	Dynamic Field in Personal Preferences

en	This setting is an example of how to create an entry in the user preferences screen to set an exclusive dynamic field ``Name_X`` default value for the selected user. The limitation of this setting is that it only permits the use of one dynamic field. If two or more fields will use this feature, it is necessary to create a custom XML configuration file to add more settings similar to this one.

en	If more settings are added in a new XML each setting name needs to be unique in the system and different than ``PreferencesGroups###DynamicField``. For example:

en	``PreferencesGroups###101-DynamicField-Field1``

en	``PreferencesGroups###102-DynamicField-Field2``

en	``PreferencesGroups###My-Field1``

en	``PreferencesGroups###My-Field2``

en	Generic Agent

en	Processing tickets requires often a workflow. Let's say "if-then" activities.

en	If specific conditions match like:

en	A ticket is from one particular customer.

en	A ticket is assigned to an appropriate queue.

en	A ticket has a defined priority.

en	A ticket contains defined keywords.

en	Outlined activities must be performed like changing the ticket priority, moving the ticket to another group, assigning a service to a ticket, and many more.

en	Also time-based activities can be required like cleaning up the spam-queue once a week.

en	OTOBO supports this with the *Generic Agent*. Here, simple or compound time and event-based tasks are configurable in the OTOBO front end without the requirement to learn a scripting language. Depending on search criteria, and time or event criteria, tickets will automatically be acted upon.

en	Use this screen to manage generic agent jobs in the system. A fresh OTOBO installation contains no generic agent jobs by default. The generic agent job management screen is available in the *Generic Agent* module of the *Processes & Automation* group.

en	Generic Agent Management Screen

en	Manage Generic Agent Jobs

en	To create a new generic agent job:

en	Click on the *Add Job* button in the left sidebar.

en	Create New Generic Agent Job Screen

en	To edit a generic agent job:

en	Click on a generic agent job in the list of generic agent jobs.

en	Edit Generic Agent Job Screen

en	To delete a generic agent job:

en	Click on the trash icon in the fourth column of the overview table.

en	Delete Generic Agent Job Screen

en	If several generic agent jobs are added to the system, use the filter box to find a particular generic agent job by just typing the name to filter.

en	Generic Agent Job Settings

en	General Job Settings

en	Job Settings - General

en	Job Name \*

en	Set the validity of this resource. This resource can be used in OTOBO only, if this field is set to *Yes*. Setting this field to *No* will disable the use of the resource.

en	Automatic Execution

en	Fill in this section to set the times for automatic execution of the job.

en	Job Settings - Automatic Execution

en	Schedule minutes

en	Select the minutes in which the job has to be executed. For example if *10* is selected, the job will be executed in every hour in 00:10, 01:10, 02:10, etc.

en	Schedule hours

en	Select the hours in which the job has to be executed. For example if *10* is selected for minutes and *02* is selected for hours, the job will be executed in every day in 02:10.

en	Schedule days

en	Select the days in which the job has to be executed. For example if *10* is selected for minutes, *02* is selected for hours and *Fri* is selected for days, the job will be executed in every week in Friday 02:10.

en	Event Based Execution

en	Fill in this section to set events that trigger the execution of the job.

en	Job Settings - Event Based Execution

en	Event Triggers

en	This is a list of already added events. If no events are added yet, the list contains no elements. Elements can be deleted by clicking on the trash icon in the last column.

en	Add Event Trigger

en	Select an object and a related event that will trigger the job.

en	If multiple Generic Agents are triggered by the same event, they will be executed in the lexicographical order, i.e. `1-Agent` before `A-Agent`.

en	Select Tickets

en	This section contains all the attributes, that you can use to select the affected tickets.

en	Fields are self-explained, so there is no additional explanation here.

en	Update/Add Ticket Attributes

en	Fill in this section to update and/or add ticket attributes.

en	Add Note

en	Fill in this section to add a note to tickets that are affected by job execution.

en	Job Settings - Add Note

en	Execute Ticket Commands

en	Fill in this section, if you would like to make execute a custom command with the job.

en	Job Settings - Execute Ticket Commands

en	Send agent/customer notifications on changes

en	If *Yes* is selected, a notification will be sent to agents and customers about ticket changes.

en	CMD

en	Enter a command here, that will be executed. ARG[0] will be the ticket number. ARG[1] the ticket ID.

en	Use ``::`` as directory separator, if the value contains a path.

en	Delete tickets

en	If *Yes* is selected, the generic agent job will delete the matched tickets.

en	All affected tickets will be removed from the database and cannot be restored!

en	Execute Custom Module

en	Fill in this section, if you would like to make execute a custom module with the job.

en	Job Settings - Execute Custom Module

en	Module

en	This is the path for the module to be executed.

en	Param key

en	Enter the key of the parameter, that should be passed to the module.

en	Param value

en	Enter the value of the parameter, that should be passed to the module.

en	Process Management

en	Maximizing performance while minimizing human error is a requirement of organizations of all sizes. This need is covered by defined processes and workflows, for recurring tasks. Ensuring all required information is available in the right place, and contacts are informed about their responsibilities like adding information, approving requests, etc.

en	OTOBO supports this requirement by process management. Process tickets help by using the required mandatory and optional fields (see :doc:`dynamic-fields`) that information is not forgotten upon ticket creation or during later steps of the process. Process tickets are simple to handle for customer users and agents, so no intensive training is required.

en	Processes are designed completely and efficiently within the OTOBO front end to fit the requirements of your organization.

en	Use this screen to manage processes in the system. The process management screen is available in the *Process Management* module of the *Processes & Automation* group.

en	Manage Processes

en	To create a new process:

en	Click on the *Create New Process* button in the left sidebar.

en	Add activities, activity dialogs, transitions and transition actions.

en	Set *State* to *Active*.

en	Deploy all processes.

en	Create New Process Screen

en	To edit a process:

en	Click on a process in the list of processes.

en	Modify the fields and the process path.

en	To copy a process:

en	Click on the copy icon in the fifth column of list of processes.

en	Click on the newly created process to edit it.

en	To delete a process:

en	Set the *State* option to *Inactive*.

en	Click on the *Save* button. A new *Delete Inactive Process* button will appear in the left sidebar.

en	Click on the *Delete Inactive Process* button.

en	Processes are written into file in Perl format. Without deploying, all processes are still in this cache file even if they are deleted or the *State* option is set to *Inactive* or *FadeAway*. Don't forget to deploy all processes after modifications!

en	Give some time for agents to complete the running process tickets before the process will be deleted. It is possible to mark a process for deletion, i. e. set the process as not to be selected anymore. Process states can be:

en	Active

en	Processes can be used in new process tickets.

en	FadeAway

en	Processes cannot be selected any more for new tickets, but existing tickets still can use the process.

en	Inactive

en	Processes are deactivated and cannot be used for new or existing tickets.

en	To deploy all processes:

en	Click on the *Deploy All Processes* button in the left sidebar.

en	New or modified processes have to deploy in order to make affect the behavior of the system. Setting the *State* option to *Active* just indicates, which processes should be deployed.

en	To export a process:

en	Click on the export icon in the fourth column of list of processes.

en	Choose a location in your computer to save the ``Export_ProcessEntityID_xxx.yml`` file.

en	The exported file contains only the process itself, and doesn't contain the :doc:`../ticket-settings/queues`, :doc:`../users-groups-roles/agents`, :doc:`dynamic-fields`, etc., needed for the process.

en	To import a process:

en	Click on the *Browse…* button of the *Configuration Import* widget in the left sidebar.

en	Click on the *Import process configuration* button.

en	Before import of a process, it is still necessary to create all :doc:`../ticket-settings/queues`, :doc:`../users-groups-roles/agents` and :doc:`dynamic-fields`, as well as to set :doc:`../administration/system-configuration`, that are needed by each process before the import. If the process requires the use of :doc:`access-control-lists` those are also needed to be set manually.

en	If several processes are added to the system, use the filter box to find a particular process by just typing the name to filter.

en	Direct Submit functionality

en	The DirectSubmit functionality allows for a streamlined user experience by bypassing the additional process dialog in both agent and customer interfaces when required. When all fields in an activity dialog within the process management system are configured to operate in the background (not displayed or shown to the user), the "Direct Submit" option can be enabled. This ensures that actions such as acceptance or denial are executed immediately upon submitting the corresponding action, without the need for an extra confirmation step.

en	Direct Submit Field

en	By implementing DirectSubmit, organizations can optimize their process management workflows, ensuring that actions are executed swiftly and with minimal user intervention.

en	If one of the fields is set to be shown, the message error “This property won't take effect because there are fields configured as visible.” will be displayed.

en	Example process

en	Processes are more complex than other resources in OTOBO. To create a process, you need to do several steps. The following chapters show you, how to define a process from the specification and create the needed resources. Let's see an example to make it more demonstrative. We will define a book order process.

en	Process Specification

en	The book order process has four states.

en	Recording the demand

en	Before an order will be placed, the demand for literature by an employee will be recorded. The following book is needed in our example:

en	Approval by manager

en	The head of the employee's department needs to decide on the order. In case of a denial, a reason should be recorded by the manager. In case of approval, the order is passed to the purchasing department.

en	Processing by purchasing department

en	Purchasing now has the task to find out where the book can be ordered with the best conditions. If it is out of stock, this can be recorded in the order. In case of a successful order purchasing will record the supplier, the price and the delivery date.

en	Processing by the mail room

en	The shipment will arrive at the company. The incoming goods department checks the shipment and records the date of receipt. Now the employee will be informed that their order has arrived and is ready to be collected.

en	Introduce The Process Elements

en	If we assume that a ticket acts in this workflow like an accompanying document that can receive change notes, we already have a clear picture of process tickets.

en	From the analysis of the example process we can identify the following necessary items:

en	Possibility to record data, let's call this :term:`activity dialog`.

en	Check which can react to changed data automatically, let's call this :term:`transition`.

en	Change which can be applied to a process ticket after successful transitions of a process ticket, let's call this :term:`transition action`.

en	A possibility to offer more than just one activity dialog to be available. In our example this is needed when the manager must have the choice between *Approve* and *Deny*. Let's call this :term:`activity`.

en	Now, with activities, activity dialogs, transitions and transition actions we have the necessary tools to model the individual steps of our example. What is still missing is an area where for each workflow the order of the steps can be specified. Let's call this :term:`process`.

en	Create Necessary Resources

en	Before the creation of the process and its parts is necessary to prepare the system. We need to define some :doc:`../ticket-settings/queues`, :doc:`../users-groups-roles/agents` and :doc:`dynamic-fields` as well as set some :doc:`../administration/system-configuration` settings.

en	Create the following :doc:`../ticket-settings/queues`:

en	Management

en	Employees

en	Purchasing

en	Post office

en	Create the following :doc:`../users-groups-roles/agents`:

en	Manager

en	Employee

en	Create the following :doc:`dynamic-fields`:

en	Type

en	Name

en	Label

en	Ticket

en	Text

en	``Title``

en	``Author``

en	Author

en	``ISBN``

en	ISBN

en	Dropdown

en	``Status``

en	Status

en	Approval

en	Approval denied

en	Approved

en	Order denied

en	Order placed

en	Shipment received

en	``Supplier``

en	Supplier

en	``Price``

en	Price

en	Date

en	``DeliveryDate``

en	Delivery date

en	``DateOfReceipt``

en	Date of receipt

en	Set the following :doc:`../administration/system-configuration` settings:

en	``Ticket::Responsible``

en	Enabled

en	``Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicFieldGroups``

en	``Book`` → ``Title,Author,ISBN``

en	``General`` → ``Status``

en	``Order`` → ``Price,Supplier,DeliveryDate``

en	``Shipment`` → ``DateOfReceipt``

en	``Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicField``

en	``Author`` → *1 - Enabled*

en	``DateOfReceipt`` → *1 - Enabled*

en	``DeliveryDate`` → *1 - Enabled*

en	``ISBN`` → *1 - Enabled*

en	``Price`` → *1 - Enabled*

en	``Status`` → *1 - Enabled*

en	``Supplier`` → *1 - Enabled*

en	``Title`` → *1 - Enabled*

en	Don't forget to deploy the modified system configuration settings.

en	Now, go back to the *Process Management* screen and click on the *Create New Process*. Fill in the required fields.

en	Book Ordering - Create New Process

en	The new process is created. You can add some process element now.

en	Create Activity Dialogs

en	Click on the *Activity Dialogs* item in the *Available Process Elements* widget in the left sidebar. This action will expand the *Activity Dialogs* options and will collapse all others doing an accordion like effect. Click on the *Create New Activity Dialog* button.

en	Book Ordering - Activity Dialogs

en	In the opened popup screen fill in the *Dialog Name* as well as the *Description (short)* fields. For this example we will leave all other fields as the default.

en	Book Ordering - Add Activity Dialog

en	To assign fields to the activity dialog simple drag the required field from the *Available Fields* pool and drop into the *Assigned Fields* pool. The order in the *Assigned Fields* pool is the order as the fields will have in the screen. To modify the order simply drag and drop the field within the pool to rearrange it in the correct place.

en	In this example we will use:

en	``Article`` field for comments.

en	``DynamicField_Title``, ``DynamicField_Author``, ``DynamicField_ISBN`` fields for the data to be collected for the order.

en	``DynamicField_Status`` with the possibility to choose *Approval*.

en	Drag these fields from the *Available Fields* pool and drop into the *Assigned Fields* pool.

en	In this screen all dynamic fields has the prefix ``DynamicField_`` as in ``DynamicField_Title``. Do not confuse with the field ``Title`` that is the ticket title.

en	Book Ordering - Add Activity Dialog Fields

en	As soon as the fields are dropped into the *Assigned Fields* pool another popup screen is shown with some details about the field. We will leave the default options and only for ``Article`` fields we should make sure that the *Communication Channel* field is set to *OTOBO* and that the *Is visible for customer* is not checked.

en	Book Ordering - Edit Activity Dialog Fields

en	After all fields are filled in, click on the *Save and finish* button to save the changes and go back to the process management screen.

en	Create the following activity dialogs with fields:

en	*Recording the demand* (already created before)

en	*Approval denied*

en	``DynamicField_Status`` with the possibility to choose *Approval denied*.

en	*Approved*

en	``DynamicField_Status`` with the possibility to choose *Approved*.

en	*Order denied*

en	``DynamicField_Status`` with the possibility to choose *Order denied*.

en	*Order placed*

en	``DynamicField_Supplier``, ``DynamicField_Price``, ``DynamicField_DeliveryDate`` fields for purchasing.

en	``DynamicField_Status`` with the possibility to choose *Order placed*.

en	*Shipment received*

en	``DynamicField_DateOfReceipt`` for the mail room.

en	``DynamicField_Status`` with the possibility to choose *Shipment received*.

en	Create Transitions

en	Click on the *Transitions* item in the *Available Process Elements* widget in the left sidebar. This action will expand the *Transitions* options and will collapse all others doing an accordion like effect. Click on the *Create New Transition* button.

en	Book Ordering - Transitions

en	In the opened popup screen fill in the *Transition Name*. For this example in the *Condition Expressions* we will use just one condition expression and just one field. For both we can leave the *Type of Linking* as *and* and we will use the filed match type value as *String*.

en	Book Ordering - Add Transition

en	Create the following transitions:

en	*Approval* (already created before)

en	Check if the ``DynamicField_Status`` is set to *Approval*.

en	Check if the ``DynamicField_Status`` field is set to *Approval denied*.

en	Check if the ``DynamicField_Status`` field is set to *Approved*.

en	Check if the ``DynamicField_Status`` field is set to *Order denied*.

en	Check if the ``DynamicField_Status`` field is set to *Order placed*.

en	Check if the ``DynamicField_Status`` field is set to *Shipment received*.

en	Create Transition Actions

en	Click on the *Transition Actions* item in the *Available Process Elements* widget in the left sidebar. This action will expand the *Transition Actions* options and will collapse all others doing an accordion like effect. Click on the *Create New Transition Action* button.

en	Book Ordering - Transition Actions

en	In the opened popup screen fill in the *Transition Action Name* and the *Transition Action module* then click on the *Save* button. A new *Configure* button will appear next to the module field.

en	Book Ordering - Add Transition Action

en	Click on the *Configure* button and add the needed configuration parameter keys and values.

en	Book Ordering - Transition Action Parameters

en	Each module has its own and different parameters. As soon as you add a TransitionAction, the options are displayed directly. Further information can currently only be found in the source code:

en	`DynamicFieldSet <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/DynamicFieldSet.pm>`_

en	`TicketArticleCreate <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/TicketArticleCreate.pm>`_

en	`TicketCreate <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/TicketCreate.pm>`_

en	`TicketCustomerSet <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/TicketCustomerSet.pm>`_

en	`TicketLockSet <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/TicketLockSet.pm>`_

en	`TicketOwnerSet <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/TicketOwnerSet.pm>`_

en	`TicketQueueSet <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/TicketQueueSet.pm>`_

en	`TicketResponsibleSet <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/TicketResponsibleSet.pm>`_

en	`TicketServiceSet <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/TicketServiceSet.pm>`_

en	`TicketSLASet <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/TicketSLASet.pm>`_

en	`TicketStateSet <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/TicketStateSet.pm>`_

en	`TicketTitleSet <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/TicketTitleSet.pm>`_

en	`TicketTypeSet <https://github.com/RotherOSS/otobo/blob/rel-10_1/Kernel/System/ProcessManagement/TransitionAction/TicketTypeSet.pm>`_

en	All transition action modules are located in the legacy named ``Kernel/System/ProcessManagement/TransitionAction``.

en	Create the following transition actions:

en	*Move the process ticket into the "Management" queue* (already created before)

en	To be executed when the transition *Approval* applied.

en	*Change ticket responsible to "Manager"*

en	*Move process ticket into the "Employees" queue*

en	To be executed when:

en	The transition *Approval denied* applied.

en	The transition *Order denied* applied.

en	The transition *Shipment received* applied.

en	*Change ticket responsible to "Employee"*

en	*Move process ticket into the "Purchasing" queue*

en	To be executed when the transition *Approved* applied.

en	*Move process ticket into the "Post office" queue*

en	To be executed when the transition *Order placed* applied.

en	*Close ticket successfully*

en	To be executed when the transition *Shipment received* applied.

en	*Close ticket unsuccessfully*

en	There are places where the same transition actions should be executed. Therefore it is reasonable to make it possible to link transition actions freely with transitions to be able to reuse them.

en	Create Activities

en	Click on the *Activities* item in the *Available Process Elements* widget in the left sidebar. This action will expand the *Activities* options and will collapse all others doing an accordion like effect. Click on the *Create New Activity* button.

en	Book Ordering - Activities

en	In the opened popup screen fill in the *Activity name* field and select *User task activity* from the *Activity type* drop-down.

en	Book Ordering - Add Activity

en	To assign dialogs to the activity simple drag the required dialogs from the *Available Activity Dialogs* pool and drop into the *Assigned Activity Dialogs* pool. The order in the *Assigned Activity Dialogs* pool is the order as the dialogs will be presented in the *Ticket Zoom* screen. To modify the order simply drag and drop the dialog within the pool to rearrange it in the correct place.

en	This order is specially important in the first activity, since the first activity dialog for this activity is the only one that is presented when the process starts.

en	In this example we need to assign only the *Recording the demand* activity dialog. Drag this dialog from the *Available Activity Dialogs* pool and drop into the *Assigned Activity Dialogs* pool.

en	Book Ordering - Assign Activity Dialog

en	Create the following activities:

en	Assign the activity dialog *Recording the demand*.

en	*Approval*

en	Assign the activity dialogs *Approval denied* and *Approved*.

en	*Order*

en	Assign the activity dialogs *Order denied* and *Order placed*.

en	*Incoming*

en	Assign the activity dialog *Shipment received*.

en	*Process complete*

en	This is an activity without possible activity dialogs. It will be set after *Approval denied*, *Order denied* or *Shipment received* and represents the end of the process.

en	Now we can clearly see that activities are precisely defined states of a process ticket. After a successful transition a process ticket moves from one activity to another.

en	Create Process Path

en	Let us conclude our example with the last missing piece in the puzzle, the process as a flow describer. In our case this is the whole ordering workflow. Other processes could be office supply ordering or completely different processes.

en	The process has a starting point which consists of the start activity and the start activity dialog. For any new book order, the first activity dialog of the first activity is the first screen that is displayed. If this is completed and saved, the process ticket will be created and can follow the configured workflow.

en	The process also contains the directions for how the process ticket can move through the process. Let's call this :term:`process path`. It consists of the start activity, one or more transitions (possibly with transition actions) and other activities.

en	Assuming that the activities have already assigned their activity dialogs, drag an activity from the accordion in the *Available Process Elements* widget in the left sidebar and drop it into the canvas area below the process information. Notice that an arrow from the process start (white circle) to the activity is placed automatically. This is the first activity and its first activity dialog is the first screen that will be shown when the process starts.

en	Book Ordering - First Activity On Canvas

en	Next, drag another activity into the canvas too. Now we will have two activities in the canvas. The first one is connected to the start point and the second has no connections. You can hover the mouse over each activity to reveal their own activity dialogs.

en	Book Ordering - Second Activity On Canvas

en	Then let's create the process path (connection) between this two activities. For this we will use the transitions. Click on transition in the accordion, drag a transition and drop it inside the first activity. As soon as the transition is dropped the end point of the transition arrow will be placed next to the process start point. Drag the transition arrow end point and drop it inside the other activity to create the connection between the activities.

en	Book Ordering - First Transition On Canvas

en	Now that the process path between the actions is defined, then we need to assign the transition actions to the transition. Double click the transition label in the canvas to open a new popup window.

en	Book Ordering - Assign First Transition Action

en	After the transition actions are assigned, click on the *Save* button to go back to the main process edit screen. Click on *Save* button below the canvas to save all other changes.

en	Complete the process path by adding the following activities, transitions and transition actions:

en	Possible transition: *Approval*

en	Starting activity: *Recording the demand*

en	Next activity: *Approval*

en	If the condition of this activity is fulfilled, the ticket will move to activity *Approval*.

en	Additionally, the following transition actions are executed:

en	*Move the process ticket into the "Management" queue*

en	The activity *Recording the demand* is a defined step of the process ticket, where there is the possibility for the transition *Approval*. If this applies, the ticket will move to the next activity *Approval*, and the transition actions *Move the process ticket into the "Management" queue* and *Change ticket responsible to "Manager"* are executed. In the activity *Approval*, the activity dialogs *Approval denied* and *Approved* are available.

en	Possible transition: *Approval denied*

en	Starting activity: *Approval*

en	Next activity: *Process complete*

en	If this matches, the process ticket will move to activity *Process complete*.

en	Possible transition: *Approved*

en	Next activity: *Order*

en	If this matches, the process ticket will move to activity *Order*.

en	We can see that from the current activity, which defines a step of the process ticket, there are one or more possibilities for transition which have exactly one target activity (and possibly one or more transition actions).

en	Possible transition: *Order denied*

en	Starting activity: *Order*

en	Possible transition: *Order placed*

en	Next activity: *Incoming*

en	If this matches, the process ticket will move to activity *Incoming*.

en	Possible transition: *Shipment received*

en	Starting activity: *Incoming*

en	The complete process path for the book ordering process will then look like this:

en	Book Ordering - Process Complete

en	After you finish the process path, click on *Save and finish* button below the canvas to go back to the process management screen.

en	Click on the *Deploy All Processes* button in the left sidebar. This will gather all processes information form the database and create a cache file (in Perl language). This cache file is actually the processes configuration that the system will use to create or use process tickets.

en	Any change that is made on the process will require to re-deploy the process in order to get the change reflected in the system.

en	Ticket Masks

en	Ticket masks can be used to define dynamic field arrangements for all ticket edit masks in more sophisticated ways. They enable multi column arrangements of dynamic fields, alternate labels and read only fields. Under Admin->Ticket Masks, for all actions a yaml defining the dynamic field section of the mask can be provided. Dynamic fields added to a mask via SysConfig (e.g. via DynamicField Screens), not present in the yaml definition, will be added as list below the defined fields.

en	An example configuration would be:

en	The basic structure of the yaml is an array of hashes.

en	On the first level ``DF`` and ``Grid`` are necessary keys for each hash, where ``DF`` causes a dynamic field to be rendered, and Grid defines a multi column section.

en	Valid keys extending ``DF`` are outside of a grid ``Mandatory``, ``Readonly`` and ``Label``.

en	In a ``Grid`` ``Columns`` set the number of columns, with the optional ``ColumnWidth`` the column width can be set.

en	``ColumnWidth`` accepts many css width definitions, usually it is recommended to use ``fr`` (fractions of the left over space), and absolute units (e.g. ``px``) only for checkboxes for example. ``2fr 3fr 60px`` would set the third column to 60 px, and distribute 2/5 of the remaining space to the first, 3/5 to the second column. ``auto`` can be used, but the column width won't stay the same between multiple rows, thus it is only recommended for single rows.

en	Lastly the ``Rows`` key with a 2D array as value defines the grid of dynamic fields.

en	In a grid ``ColumnStart`` and ``ColumnSpan`` are additional valid keys for ``DF``, placing them at certain locations within a row.

en	Web Services

en	In a connected world, a ticket system needs to be able to react to requests from other systems and also to send requests or information to other systems:

en	CRM systems

en	Project management systems

en	Documentation management systems

en	and many more

en	The ticket system must be reachable by other services without manual intervention by an agent.

en	OTOBO supports this requirement by the *Generic Interface*. It empowers the administrator to create a web service for a specific task without scripting language knowledge. OTOBO reacts on incoming REST or SOAP requests and creates objects or provides object data to other systems transparently.

en	A web service is a communication method between two systems, in our case OTOBO and a remote system. In its configuration, the :term:`operation` or :term:`invoker` determine the direction of communication, and the :term:`mapping` and :term:`transport` take care of how the data is received and interpreted.

en	By configuration, you can define what actions the web service can perform internally (operation), what actions the OTOBO request can perform on a remote system (invokers), how data is converted from one system to the other (mapping), and which protocol is used for communication (transport).

en	The generic interface is the framework which makes it possible to create web services for OTOBO in a predefined way, using ready-made building blocks that are independent from each other and interchangeable.

en	Use this screen to manage web services in the system. A fresh OTOBO installation contains no web service by default. The web service management screen is available in the *Web Services* module of the *Processes & Automation* group.

en	Web Service Management Screen

en	Manage Web Services

en	To create a web service:

en	Click on the *Add Web Service* button in the left sidebar.

en	Fill-in the required fields.

en	Create New Web Service Screen

en	To edit a web service:

en	Click on a web service in the list of web services.

en	Edit Web Service Screen

en	To delete a web service:

en	Click on the *Delete Web Service* button in the left sidebar.

en	Click on the *Delete* button in the confirmation dialog.

en	Delete Web Service Screen

en	To clone a web service:

en	Click on the *Clone Web Service* button in the left sidebar.

en	Enter a new name for the web service.

en	Clone Web Service Screen

en	To export a web service:

en	Click on the *Export Web Service* button in the left sidebar.

en	Choose a location in your computer to save the ``Export_ACL.yml`` file to.

en	All stored passwords in the web service configuration will be exported in plain text format.

en	To see the configuration history of a web service:

en	Click on the *Configuration History* button in the left sidebar.

en	Web Service Configuration History Screen

en	To use the debugger for a web service:

en	Click on the *Debugger* button in the left sidebar.

en	Web Service Debugger Screen

en	To import a web service:

en	Click on the *Import Web Service* button in the left sidebar.

en	Click on the *Browse…* button in the dialog.

en	Add a name for the imported web service (optional). Otherwise the name will be taken from the configuration file name.

en	Click on the *Import* button.

en	Web Service Settings

en	General Web Service Settings

en	Web Service Settings - General

en	Remote system

en	Debug threshold

en	The default value is *Debug*. When configured in this manner, all communication logs are registered in the database. Each subsequent debug threshold value is more restrictive and discards communication logs of lower order than the one set in the system.

en	Debug threshold levels (from lower to upper):

en	Debug

en	Info

en	Notice

en	Error

en	Set the validity of this resource. Resources can only be used in OTOBO if this field is set to *valid*. Setting this field to *invalid* or *invalid-temporarily* will disable the use of the resource.

en	Provider Web Service Settings

en	To access the otobo webservice, please use the following URL:

en	Web Service Settings - OTOBO as Provider

en	Network transport

en	Select which network transport you would like to use with the web service. Possible values are *HTTP::REST* and *HTTP::SOAP*.

en	After selecting the transport method, you have to save the configuration by clicking on the *Save* button. A *Configuration* button will be displayed next to this field.

en	Configuration

en	The *Configuration* button is visible only after a network transport was selected and saved. See the configuration for *OTOBO as Provider - HTTP\:\:REST* and *OTOBO as Provider - HTTP\:\:SOAP* below.

en	Add Operation

en	This option is visible only after a network transport was selected and saved. Selecting an operation will open a new screen for configuration.

en	Web Service Settings - OTOBO as Provider - Operation

en	OTOBO as Provider - HTTP\:\:REST

en	To use the OTOBO REST interface, choose the network transport method "HTTP\:\:REST". Save and reload the screen to load the ticket operations.

en	Web Service Settings - OTOBO as Provider - HTTP\:\:REST

en	You should now be able to select an operation.

en	Operations

en	There are different Ticket Operations which all serve a specific job:

en	`Ticket::TicketCreate`

en	`Ticket::TicketGet`

en	`Ticket::TicketSearch`

en	`Ticket::TicketUpdate`

en	`Ticket::TicketHistoryGet`

en	In this example, we are going to use the Ticket::TicketCreate operation. Click on "Add Operation" and choose the "Ticket::TicketCreate" operation. Choose a descriptive name, save the operation and go back to the webservice overview.

en	You now should see a new entry "Route mapping for Operation 'TicketCreate'". Enter for example "/TicketCreate"

en	This will define the route, which will translate to: ``https://YOURSERVER/otobo/nph-genericinterface.pl/Webservice/<WEBSERVICE_NAME>/TicketCreate``

en	Click "Save and finish".

en	Now you can send a request to the endpoint.

en	Here is an example using curl:

en	This request is using the least amount of attributes needed to create a new ticket.

en	A full list of all attributes needed for operations can be found here:

en	TicketCreate: https://github.com/RotherOSS/otobo/blob/rel-11_0/Kernel/GenericInterface/Operation/Ticket/TicketCreate.pm#L77

en	TicketGet: https://github.com/RotherOSS/otobo/blob/rel-11_0/Kernel/GenericInterface/Operation/Ticket/TicketGet.pm#L73

en	TicketUpdate: https://github.com/RotherOSS/otobo/blob/rel-11_0/Kernel/GenericInterface/Operation/Ticket/TicketUpdate.pm#L77

en	TicketSearch: https://github.com/RotherOSS/otobo/blob/rel-11_0/Kernel/GenericInterface/Operation/Ticket/TicketSearch.pm#L70

en	TicketHistoryGet: https://github.com/RotherOSS/otobo/blob/rel-11_0/Kernel/GenericInterface/Operation/Ticket/TicketHistoryGet.pm#L67

en	XSLT-Mapping for OTOBO as Provider - HTTP\:\:REST

en	The XSLT standard can be used to transform XML, JSON and CSV data.

en	In this example, we are going to use the XSLT mapping to transform the response from the webservice into Dynamic Fields.

en	Create a Dynamic Field of Type Ticket->Text and name it for example "RemoteTicketID".

en	Given the incoming data:

en	We can save the data in the Dynamic Field as follows:

en	OTOBO as Provider - HTTP\:\:SOAP

en	Web Service Settings - OTOBO as Provider - HTTP\:\:SOAP

en	Requester Web Service Settings

en	Web Service Settings - OTOBO as Requester

en	Select which network transport would you like to use with the web service. Possible values are *HTTP::REST* and *HTTP::SOAP*.

en	After selecting the transport method, you have to save the configuration by clicking the *Save* button. A *Configuration* button will be displayed next to this field.

en	The *Configuration* button is visible only after a network transport was selected and saved. See the configuration for *OTOBO as Requester - HTTP\:\:REST* and *OTOBO as Requester - HTTP\:\:SOAP* below.

en	Add error handling module

en	This option is visible only after a network transport was selected and saved. Selecting an operation will open a new screen for its configuration.

en	Web Service Settings - OTOBO as Provider - Error Handling Module

en	OTOBO as Requester - HTTP\:\:REST

en	Web Service Settings - OTOBO as Requester - HTTP\:\:REST

en	OTOBO as Requester - HTTP\:\:SOAP

en	Web Service Settings - OTOBO as Requester - HTTP\:\:SOAP

en	Ticket Settings

en	A :term:`ticket` is similar to a medical report created for a hospital patient. When a patient first visits the hospital, a medical report is created to hold all necessary personal and medical information on him. Over multiple visits, as he is attended to by the same or additional doctors, the attending doctor updates the report by adding new information on the patient's health and the ongoing treatment. This allows any other doctors or the nursing staff to get a complete picture on the case at hand. When the patient recovers and leaves the hospital, all information from the medical report is archived and the report is closed.

en	Ticket systems such as OTOBO handle tickets like normal emails. The messages are saved in the system. When a customer sends a request, a new ticket is generated by the system which is comparable to a new medical report being created. The response to this new ticket is comparable to a doctor's entry in the medical report. A ticket is closed if an answer is sent back to the customer, or if the ticket is separately closed by the system. If a customer responds again on an already closed ticket, the ticket is reopened with the new information added.

en	Ticket Zoom Screen

en	Every ticket is stored and archived with complete information. Since tickets are handled like normal emails, attachments and contextual annotations will also be stored with each email. In addition, information on relevant dates, employees involved, working time needed for ticket resolution, etc., are also saved. At any later stage, tickets can be sorted, and it is possible to search through and analyze all information using different filtering mechanisms.

en	Attachments

en	For any size of organization it is often required to send a service agreement, the terms of service or a privacy statement out when a customer signs a contract.

en	OTOBO can handle an infinite number of attachments (PDF, image, etc.) and can bundle them into templates. Your agents don’t need to maintain the attachments on their own, nor don’t they need to upload them again and again - they can just use the predefined templates.

en	Use this screen to add attachments for use in templates. A fresh OTOBO installation doesn't contain any attachments by default. The attachment management screen is available in the *Attachments* module of the *Ticket Settings* group.

en	Attachment Management Screen

en	Manage Attachments

en	To add an attachment:

en	Click on the *Add Attachment* button in the left sidebar.

en	Add Attachment Screen

en	To edit an attachment:

en	Click on an attachment in the list of attachments.

en	Edit Attachment Screen

en	To delete an attachment:

en	Delete Attachment Screen

en	If several attachments are added to the system, use the filter box to find a particular attachment by just typing the name to filter.

en	Attachment Settings

en	Attachment \*

en	Open the file dialog to add a file from the file system. This field is mandatory in the attachment add screen, but optional in the attachment edit screen. Adding a new file in the edit screen will overwrite the existing attachment.

en	Auto Responses

en	Quick and transparent service is vital to maintaining a good working relationship with your customer. Email, fax, social media and other non-real-time communications are patient, but you want to engage your customer immediately upon receipt of a request.

en	OTOBO allows you to respond to a customer immediately upon receipt of a request giving the customers instantaneous feedback assuring them that their request is in processing, establishing expectation.

en	Automatic responses can be sent to customers based on the occurrence of certain events, such as the creation of a ticket in a specific queue, the receipt of a follow-up message in regards to a closed or rejected ticket, etc.

en	Use this screen to add automatic responses for use in queues. A fresh OTOBO installation contains some automatic responses by default. The automatic response management screen is available in the *Auto Responses* module of the *Ticket Settings* group.

en	Auto Response Management Screen

en	Manage Auto Responses

en	Adding automatic responses requires a valid system address. Create system addresses in the :doc:`../communication-notifications/email-addresses` screen.

en	To add an automatic response:

en	Click on the *Add Auto Response* button in the left sidebar.

en	Add Auto Response Screen

en	Auto responses can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit an automatic response:

en	Click on an automatic response in the list of automatic responses.

en	Edit Auto Response Screen

en	If several automatic responses are added to the system, use the filter box to find a particular automatic response by just typing the name to filter.

en	Auto Response Settings

en	The subject of the email sent to the users.

en	Response

en	The body of the email sent to the users.

en	The event type that triggers the sending of this automatic response. Only one automatic response can be sent automatically per event. The following event types are available:

en	auto follow up

en	Is triggered for any follow-up message on an existing ticket. This includes also article notes which are visible for the customer. If the :doc:`../administration/system-configuration` option 'AutoResponseForWebTickets' is activated the automatic response is also sent for follow up articles created through the customer web interface or through a telephone call otherwise only for follow up articles created from a customer email. This automatic repsonse does not apply for new tickets, see the 'auto reply' event type.

en	auto reject

en	If the :doc:`queues` setting 'follow up option' is set to 'reject' this event will be triggered if a customer answers in a ticket, that is already closed.

en	auto remove

en	If a ticket is deleted by the system, the customer gets this automatic response.

en	auto reply

en	If a new ticket is generated the customer will get this auto response. If the :doc:`../administration/system-configuration` option 'AutoResponseForWebTickets' is activated the automatic response is also sent for new tickets created through the customer web interface or through a telephone call (telephone ticket) otherwise only for new tickets created from a customer email. This automatic repsonse does not apply if the 'auto reply/new ticket' event type occours.

en	auto reply/new ticket

en	If the :doc:`queues` setting 'follow up option' is set to 'new ticket' this event will be triggered if a customer answers in a ticket, that is already closed. You can use this message to inform the customer of the new ticket number.

en	Auto response from \*

en	The sender email address, from which the automatic response will be sent.

en	Auto Response Variables

en	Sometimes tickets are not equally created. One ticket may need more focus than another. A customer may be given a higher priority by the service desk to help raise customer satisfaction in a pinch or to ensure that a long-running request receives special attention. Keeping track of these higher priority requests is important, as well as handling them quickly.

en	OTOBO provides a traffic light system based per default five levels of priorities to handle this task.

en	Blue: very low

en	Green: low

en	Grey: normal

en	Pink: high

en	Red: very high

en	The colors are based on the ID (very low being ID 1) in the database. Changing the names should be done with this in mind. New priorities have the color gray.

en	Use this screen to add priorities to the system. A fresh OTOBO installation contains five default priority levels. The priority management screen is available in the *Priorities* module of the *Ticket Settings* group.

en	Priority Management Screen

en	Manage Priorities

en	When creating a customized list of priorities, please keep in mind that they are sorted alphabetically in the priority selection box in the user interface.

en	To add a priority:

en	Click on the *Add Priority* button in the left sidebar.

en	Add Priority Screen

en	Priorities can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	It's recommended to limit your system to 5 priorities or less and reuse the current 5 to keep the use of the traffic light system.

en	To edit a priority:

en	Click on a priority in the list of priorities.

en	Edit Priority Screen

en	If several priorities are added to the system, use the filter box to find a particular priority by just typing the name to filter.

en	Priority Validation Dialog

en	If you change the name of a priority which is used in the system configuration, a validation check will warn you and give you the following options:

en	Save and update automatically

en	Apply the change and also update the affected settings.

en	Don't save, update manually

en	Apply the change, but don't update the affected settings. The updates need to be done manually.

en	Cancel

en	Cancel the action.

en	Priority Settings

en	Teams need a workspace and the ability to dispatch work based on skill level, security level, department or responsibility just to name a few. Other teams may also need to view or react to these requests as well.

en	OTOBO uses queues to provide your teams with structure. Queues provide a powerful way to divide and disperse the work to the responsible group of people.

en	Use this screen to add queues to the system. In a fresh OTOBO installation there are 4 default queues: *Raw*, *Junk*, *Misc* and *Postmaster*. All incoming messages will be stored in the *Raw* queue if no filter rules are defined. The *Junk* queue can be used to store spam messages. The queue management screen is available in the *Queues* module of the *Ticket Settings* group.

en	Queue Management Screen

en	Manage Queues

en	To add a queue:

en	Click on the *Add Queue* button in the left sidebar.

en	Add Queue Screen

en	Queues can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit a queue:

en	Click on a queue in the list of queues.

en	Edit Queue Screen

en	If several queues are added to the system, use the filter box to find a particular queue by just typing the name to filter.

en	Queue Validation Dialog

en	If you change the name of a queue which is used in the system configuration, a validation check will warn you and give you the following options:

en	Queue Settings

en	Sub-queue of

en	It is possible to add the new queue under an existing one as sub-queue. This will be displayed as *Parent Queue::Child Queue*.

en	Group \*

en	It is possible to limit access to the selected group. The group creates a permission link between the queue and an agent or a customer user.

en	Unlock timeout minutes

en	Any ticket on open, which is locked, in this queue will automatically unlock after the set amount of minutes. The value *0* (default) means tickets in this queue remain locked.

en	Escalation - first response time (minutes)

en	The maximum amount of working time allowed before the agent contacts with the customer.

en	First response time will not trigger for an email ticket or telephone ticket created by an agent.

en	Notify by

en	Notify before time limit is reached (in percent).

en	Escalation - update time (minutes)

en	The maximum amount of working time allowed between the agent contacts with the customer.

en	Escalation - solution time (minutes)

en	The maximum amount of working time allowed until the ticket is marked as solved.

en	Solution time will not reset if the ticket is reopened.

en	Follow up Option \*

en	Specify the handling of a follow up on closed tickets. Possible values:

en	new ticket

en	The follow up will create a new ticket.

en	possible

en	The follow up will reopen the already closed ticket.

en	reject

en	The follow up will be rejected.

en	See :doc:`auto-responses` chapter for more information.

en	Ticket lock after a follow up \*

en	Only applicable if the *Follow up Option* is set to *possible*. Locks the previously closed ticket, upon reopening, to the last owner. This ensures that a follow up for a ticket is processed by the agent that has previously handled that ticket.

en	This does not take out-of-office into account. Use this setting with care to ensure or in combination with *Unlock timeout minutes*.

en	System address \*

en	Select one of the :doc:`../communication-notifications/email-addresses` as the sender identity for this queue.

en	This is an ID in the database. Making changes to the :doc:`../communication-notifications/email-addresses` can have adverse effects here.

en	Default sign key

en	This is only active if :doc:`../communication-notifications/pgp-keys` or :doc:`../communication-notifications/s-mime-certificates` is enabled in the :doc:`../administration/system-configuration`. Choose the key to sign emails per default.

en	Salutation \*

en	Select one of the defined :doc:`salutations`.

en	Signature \*

en	Select one of the defined :doc:`signatures`.

en	Select the calendar which defines working hours for this queue. Calendars are defined in the :doc:`../administration/system-configuration`.

en	Chat Channel

en	Chat channel that will be used for communication related to the tickets in this queue.

en	Queues ↔ Auto Responses

en	Communicating a change in, for example, service times, service levels or other information which would be good for a customer to know when opening a ticket can be a tedious and error-ridden task. Attempting to make sure all departments have the correct information and transmitting this to their customers poses a challenge.

en	OTOBO gives you the power to quickly assign the appropriate automatic responses to any queue, containing pertinent service information, ensuring this information reaches your customers before expectations aren't reached.

en	Use this screen to add one or more automatic responses to one or more queues. The management screen is available in the *Queues ↔ Auto Responses* module of the *Ticket Settings* group.

en	Manage Queue-Auto Response Relations

en	Manage Queues ↔ Auto Responses Relations

en	To assign an automatic response to a queue:

en	Click on a queue in the *Queues* column.

en	Select the automatic responses you would like to add the queue to.

en	Change Auto Response Relations for Queue

en	It is not possible to assign multiple queues to an automatic response by clicking on the automatic response name. A click on the automatic response will open to the :doc:`auto-responses` screen.

en	If several automatic responses or queues are added to the system, use the filter box to find a particular automatic response or queue by just typing the name to filter.

en	Queues ↔ Auto Responses Settings

en	The following settings are available when assigning some automatic responses to a queue.

en	This automatic response will be sent to users, when they send a message to the queue, and the message is not a follow-up message of a ticket.

en	This automatic response will be sent to users, when they send a message to the queue and *reject* is set as *Follow up Option* in the queue settings.

en	This automatic response will be sent to users, when they send a message to the queue and *possible* is set as *Follow up Option* in the queue settings.

en	This automatic response will be sent to users, when they send a message to the queue and *new ticket* is set as *Follow up Option* in the queue settings.

en	This automatic response will be sent to users, when the remove option is enabled.

en	*Auto reply*, *auto reject* and *auto reply/new ticket* mutually cancel each other based on the :doc:`queues` settings. Only one will take effect per queue.

en	Salutations

en	Addressing customers must be done in a standardized way. Your customers may not always be external customers requiring a less formal greeting.

en	OTOBO provides you with the tools needed to create a standardized communication form for any one of your queues. As defined in the :ref:`Queue Settings`: :doc:`salutations`, :doc:`templates`, and :doc:`signatures` are combined to ensure a well formed standardized email communication.

en	Salutations can be linked to one or more :doc:`queues`. A salutation is used only in email answers to tickets.

en	Use this screen to add salutations to the system. A fresh OTOBO installation already contains a standard salutation. The salutation management screen is available in the *Salutations* module of the *Ticket Settings* group.

en	Salutation Management Screen

en	Manage Salutations

en	To add a salutation:

en	Click on the *Add Salutation* button in the left sidebar.

en	Add Salutation Screen

en	Salutations can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit a salutation:

en	Click on a salutation in the list of salutations.

en	Edit Salutation Screen

en	If several salutations are added to the system, use the filter box to find a particular salutation by just typing the name to filter.

en	Before invalidating this object, please go to the *Queues* module of the *Ticket Settings* group and make sure all queues using this setting are using a valid object.

en	Salutation Settings

en	The text that will be placed to the beginning of new emails.

en	Salutation Variables

en	For example, the variable ``<OTOBO_CUSTOMER_DATA_UserLastname>`` expands to the customer's last name to be included in something like the following.

en	Service Level Agreements

en	Your organization must meet the time demands of your customers. Timely service matters. Response to questions, updates on issues, and solutions must be provided in an agreed amount of time. The agent must receive notification of possible breaches, to prevent ticket escalation.

en	OTOBO scales well with your needs and offers management of service level agreements (SLAs). OTOBO provides you with the possibility to create numerous service level agreements covering all of your service and customer need. Each :term:`SLA` can cover multiple services and define the availability of service and escalation periods.

en	Use this screen to add service level agreements to the system. A fresh OTOBO installation doesn't contain any service level agreements by default. The service level agreement management screen is available in the *Service Level Agreements* module of the *Ticket Settings* group.

en	Service Level Agreement Management Screen

en	To use this feature, ``Ticket::Service`` must be activated in the :doc:`../administration/system-configuration` under the *Administration* group to be selectable in the ticket screens. You may click on the link in the warning message of the notification bar to directly jump to the configuration setting.

en	Manage Service Level Agreements

en	Adding service level agreements requires, that at least one service is added to the system. Create services in the :doc:`services` screen.

en	To add a service level agreement:

en	Click on the *Add SLA* button in the left sidebar.

en	Add Service Level Agreement Screen

en	Service level agreements can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit a service level agreement:

en	Click on a service level agreement in the list of service level agreements.

en	Edit Service Level Agreement Screen

en	If several service level agreements are added to the system, use the filter box to find a particular service level agreement by just typing the name to filter.

en	Service Level Agreement Settings

en	SLA \*

en	Service

en	Select one or more of the :doc:`services` to be assigned to this SLA.

en	Dialog message

en	Is being displayed if a customer chooses this SLA on ticket creation (only in the external interface).

en	Requests to your service desk should be categorized based on affected :term:`service` to correctly reach a team of experts to deal with the issue. Because not all your agents can deal with specific problems. Lack of experience or access to resources to fix an issue requires defining the service affected in a ticket helps to categorize the issue and target the correct teams.

en	OTOBO allows adding all services offered to your customers. These services may be later bound to :doc:`service-level-agreements` to ensure a timely solution based on customer-specific agreements.

en	Use this screen to add services to the system. A fresh OTOBO installation doesn't contain any services by default. The service management screen is available in the *Services* module of the *Ticket Settings* group.

en	Service Management Screen

en	Manage Services

en	To add a service:

en	Click on the *Add Service* button in the left sidebar.

en	Add Service Screen

en	Services can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit a service:

en	Click on a service in the list of services.

en	Edit Service Screen

en	If several services are added to the system, use the filter box to find a particular service by just typing the name to filter.

en	Service Settings

en	Service \*

en	Sub-service of

en	It is possible to add the new service under an existing one as sub-service. This will be displayed as *Parent Service::Child Service*.

en	A service can only be selectable in the ticket screens, if the service is assigned to the customer user of the ticket or it is set as default service for all customer users in the :doc:`../users-groups-roles/customer-users-services` screen.

en	Signatures

en	Corporate identity and team information are essential in each communication. The name of the employee writing and other vital details like disclaimers are some examples of necessary information to include in the communication with the customer.

en	OTOBO provides you with the same tools here, as with :doc:`salutations`, to create a standardized communication form for any one of your queues. As defined in the :ref:`Queue Settings`: :doc:`salutations`, :doc:`templates`, and :doc:`signatures` are combined to ensure a well formed standardized email communication.

en	Signatures can be linked to one or more :doc:`queues`. A signature is used only in email answers to tickets.

en	Use this screen to add signatures to the system. A fresh OTOBO installation already contains a standard signature. The signature management screen is available in the *Signatures* module of the *Ticket Settings* group.

en	Signature Management Screen

en	Manage Signatures

en	To add a signature:

en	Click on the *Add Signature* button in the left sidebar.

en	Add Signature Screen

en	Signatures can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit a signature:

en	Click on a signature in the list of signatures.

en	Edit Signature Screen

en	If several signatures are added to the system, use the filter box to find a particular signature by just typing the name to filter.

en	Signature Settings

en	The text that will be placed to the end of new emails.

en	Signature Variables

en	For example, the variable ``<OTOBO_CURRENT_UserFirstname> <OTOBO_CURRENT_UserLastname>`` expands to the agent's first and last name allowing a template to include something like the following.

en	State pre-selection for Templates

en	States

en	Active tracking of tickets leads to a better sense of workload and provides metrics as a key performance indicator. Sorting tasks and setting appointments can help to level-off the workload and keep your service desk running.

en	OTOBO uses ticket states to ensure that your agents always know which tickets are being attended to and which not. Additionally, detailed reports on the states of your tickets can be provided by ticket search or reports and personalized sorting is possible using dashboards and queue and service overviews.

en	Nine states are pre-defined. More states can be added, but the default states are enough to get you going and mostly enough for any situation.

en	The default states are the following:

en	closed successful

en	A ticket is complete. The customer received a solution which worked.

en	closed unsuccessful

en	A ticket is complete. The customer received no solution or the solution was not appropriate.

en	merged

en	The ticket content is found in a different ticket.

en	new

en	The ticket is created by the customer without contact with an agent.

en	open

en	The ticket is currently in progress. Customer and agent are in contact with each another.

en	pending auto close+

en	The ticket will be set as *closed successful* upon reaching the pending time.

en	pending auto close-

en	The ticket will be set as *closed unsuccessful* upon reaching the pending time.

en	pending reminder

en	The ticket should be worked on again upon reaching the pending time.

en	removed

en	The ticket has been removed from the system.

en	Pending jobs are checked per default every two hours and forty-five minutes. This time is a static time, which means the times are 02:45, 04:45, 06:45 and so on. The job can be run more often or seldom and is configured in the *System Configuration* module of the *Administration* group.

en	Use this screen to add states to the system. A fresh OTOBO installation contains several states by default. The state management screen is available in the *States* module of the *Ticket Settings* group.

en	State Management Screen

en	Manage States

en	To add a state:

en	Click on the *Add State* button in the left sidebar.

en	Add State Screen

en	States can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit a state:

en	Click on a state in the list of states.

en	Edit State Screen

en	If several states are added to the system, use the filter box to find a particular state by just typing the name to filter.

en	State Validation Dialog

en	If you change the name of a state which is used in the system configuration, a validation check will warn you and give you the following options:

en	State Settings

en	State type \*

en	Every state is linked to a type, which needs to be specified if a new state is created or an existing one is edited. The following types are available:

en	closed

en	pending auto

en	State types are predefined and cannot be changed in the software due to their special mechanics. When adding new states for *pending auto* and *pending reminder* state types you must make further configurations in the *System Configuration* module of the *Administration* group.

en	State Configuration Options

en	The following options are relevant and noteworthy. Please review these when managing states:

en	``Daemon::SchedulerCronTaskManager::Task###TicketPendingCheck``

en	``Ticket::StateAfterPending``

en	Providing the correct and consistent answer all the time regardless of employee or knowledge-level is important to maintain a professional appearance to your customers. Additionally, speed in sending standard answers is key to wading through the masses of requests in growing service desks.

en	OTOBO templates offer you a variety of ways to deal with standardizing communications and help to pre-define texts so that the customer always receives the same level and quality of service from all agents.

en	Use this screen to add templates for use in communications. A fresh OTOBO installation already contains a template by default. The template management screen is available in the *Templates* module of the *Ticket Settings* group.

en	Template Management Screen

en	Manage Templates

en	To add attachments to a template, it needs to create the attachment first in the :doc:`attachments` screen.

en	To add a template:

en	Click on the *Add Template* button in the left sidebar.

en	Add Template Screen

en	To edit a template:

en	Click on a template in the list of templates.

en	Edit Template Screen

en	To delete a template:

en	Click on the trash icon in the list of templates.

en	Delete Template Screen

en	If several templates are added to the system, a filter box is useful to find a particular template by just typing to filter.

en	Template Settings

en	There are different kind of templates that are used for different purposes. A template can be:

en	Answer

en	To be used as a ticket response or reply.

en	Create

en	To be used for new phone or email ticket.

en	Email

en	To be used for writing an email to a customer user or to someone else.

en	Forward

en	To be used to forward an article to someone else.

en	Note

en	To be used to create notes.

en	Phone call

en	To be used for inbound and outbound phone calls.

en	Process dialog

en	To be used in process management to pre-fill text of articles in user task activity dialogs.

en	Template

en	The body of the article added by the template.

en	It is possible to add one or more attachments to this template. Attachments can be added in the :doc:`attachments` screen.

en	Template Variables

en	Templates ↔ Attachments

en	Making changes to standard attachments is sometimes overwhelming. The question is, "Where were the attachments used?" or "How to quickly update them across the board?". It's also important to know who are using which attachments, before updating them. A new attachment can have multiple uses within your organization.

en	OTOBO empowers you to manage this providing you an overview to manage the 1:n relationships and quickly identify the templates using your attachments.

en	Use this screen to add one or more attachments to one or more templates. To use this function, at least one attachment and one template need to have been added to the system. The management screen is available in the *Templates ↔ Attachments* module of the *Ticket Settings* group.

en	Manage Template-Attachment Relations

en	Manage Templates ↔ Attachments Relations

en	To add some attachments to a template:

en	Click on a template in the *Templates* column.

en	Select the attachments you would like to add to the template.

en	Change Attachment Relations for Template

en	To assign an attachment to some templates:

en	Click on an attachment in the *Attachments* column.

en	Select the templates you would like to assign the attachment to.

en	Change Template Relations for Attachment

en	If several templates or attachments are added to the system, use the filter box to find a particular template or attachment by just typing the name to filter.

en	Multiple templates or attachments can be assigned in both screens at the same time. Additionally clicking on a template or clicking on an attachment in the relations screen will open the *Edit Template* screen or the *Edit Attachment* screen accordingly.

en	Accessing a template or an attachment provides no back link to the relations screen.

en	Templates ↔ Queues

en	Sharing, distributing and making changes to standard text modules and information for sharing with customers or communication between teams can be an impossible mission.

en	OTOBO can quickly aid you in ensuring that all of your teams have the correct templates available for use by assignment based on the queue.

en	Use this screen to add one or more templates to one or more queues. To use this function, at least one template and one queue need to have been added to the system. The management screen is available in the *Templates ↔ Queues* module of the *Ticket Settings* group.

en	Manage Template-Queue Relations Screen

en	Manage Templates ↔ Queues Relations

en	To assign a template to a queue:

en	Select the queues you would like to add the template to.

en	Change Queue Relations for Template

en	To assign a queue to a template:

en	Select the templates you would like to assign the queue to.

en	Change Template Relations for Queue

en	If several templates or queues are added to the system, use the filter box to find a particular template or queue by just typing the name to filter.

en	Multiple templates or queues can be assigned in both screens at the same time. Additionally clicking on a template or clicking on a queue in the relations screen will open the *Edit Template* screen or the *Edit Queue* screen accordingly.

en	Accessing a queue or a template provides no back link to the relations screen.

en	Ticket Masks Settings

en	Consistency and efficiency in handling customer inquiries are fundamental aspects for service desks aiming for excellence. The ability to customize and organize dynamic fields in ticket forms in a specific manner is essential to ensure an optimal experience for users.

en	The 'Ticket Masks' feature in OTOBO allows users to create customized templates that enable them to define the order and appearance of dynamic fields in forms precisely. This feature offers the flexibility to set titles, labels, and presentation formats such as grids, as well as the ability to make fields read-only and store multiple values for a single field in a single form.

en	With 'Ticket Masks', agents can streamline ticket management by tailoring the presentation of information to the specific needs of each situation, leading to greater operational efficiency and a more satisfying user experience.

en	Use this screen to add Ticket masks for use in communications. A new OTOBO installation already contains Ticket masks for all existing actions. The ticket mask management screen is available in the Ticket mask module of the Processes and Automation group.

en	Ticket Mask Management Screen

en	Ticket Mask management

en	To edit a ticket mask in OTOBO, follow these steps:

en	Click on the "Action" field in the left sidebar and select the action for which you want to edit the ticket mask.

en	Click on the "Change mask definition" button in the left sidebar.

en	Fill in the "Definition" field while maintaining the main structure of the ticket mask.

en	Press the "Save" or "Save and Finish" button to save the changes.

en	Edit Mask Screen

en	Ticket Mask Definitions

en	To create a ticket mask in OTOBO, it's necessary to define its configuration using the 'Definitions' field. Definitions are structures that allow specifying how dynamic fields will be displayed and organized in the ticket form.

en	Ticket Mask Definition

en	In this example, a dynamic field of type "title" is defined at the top of the definition. The label is set as "Custom Dynamic Fields" and defined as mandatory.

en	Underneath, the dynamic field "Name" is defined, also marked as mandatory.

en	Next, the configuration of the grid format in which the dynamic fields will be presented begins, defining four columns and their sizes.

en	Now, the dynamic fields that will go in each row will be defined. First, the dynamic field with the attribute 'DF' is defined, then it's specified in which column it will be using the 'ColumnStart' attribute. Additionally, the separation between that dynamic field and the next one in the same row can be defined using the 'ColumnSpan' attribute, where 1 is the default separation if the attribute is not defined.

en	Ticket Mask Rows Definition

en	Once saved and completed, the mask would appear as follows:

en	Displayed Ticket Mask

en	Types

en	Good KPIs (Key Performance Indicators) require knowing the type of work your organization performs. Not all tasks take the same amount of effort even when performed by the same team. Creating a queue structure for this purpose can be overpowered due to the amount of configuration required to create and manage a queue.

en	OTOBO provisions for KPIs with minimal overhead using ticket types. Typical types used in IT service desks are *unclassified*, *incident* and *problem*. You can quickly define new types with ease.

en	Use this screen to add types to the system. A fresh OTOBO installation contains an *unclassified* type by default. The type management screen is available in the *Types* module of the *Ticket Settings* group.

en	Type Management Screen

en	``Ticket::Type`` must first be activated via :doc:`../administration/system-configuration` under the *Administration* group to be selectable in the ticket screens. You may click on the link in the warning message to directly jump to the configuration setting.

en	Type Activation Warning

en	Manage Types

en	To add a type:

en	Click on the *Add Ticket Type* button in the left sidebar.

en	Add Type Screen

en	Types can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit a type:

en	Click on a type in the list of types.

en	Edit Type Screen

en	If several types are added to the system, use the filter box to find a particular type by just typing the name to filter.

en	Type Settings

en	Users, Groups & Roles

en	Simple and complex organizations need a flexible way to control access to their service desk. Access, resources, and permissions must be orchestrated so that, the users and customers have access to the resources they need and their data is protected as needed by the system.

en	OTOBO provides powerful tools for this purpose and their use is described in the following chapter.

en	Agents

en	Agent and access management for your service desk should be easy. Flexibility in adding, editing, invalidating access and a quick overview of which permissions a user has will help you maintain a clean permissions system and record of your setup in OTOBO.

en	OTOBO aids you giving you the power to manage agents within OTOBO across multiple back ends. OTOBO can use up-to ten back end sources, even marking some as read-only. Managing user settings centrally, an administrator can quickly invalidate a compromised account or set an account to out-of-office in case of an unexpected illness.

en	Use this screen to add agents to the system. A fresh OTOBO installation contains an agent with administrator privileges by default. The agent management screen is available in the *Agents* module of the *Users, Groups & Roles* group.

en	Agent Management Screen

en	The superuser account username is *root@localhost*. Don't use the superuser account to work with OTOBO! Create new agents and work with these accounts instead. One of the adverse effects is that :doc:`../processes-automation/access-control-lists` will not have an effect on this user.

en	Manage Agents

en	Adding or editing an agent is possible only by using database back end. Using explicitly external directory services like LDAP and, based on configuration, some databases are read-only. Personal preferences like out-of-office can still be set.

en	To add an agent:

en	Click on the *Add Agent* button in the left sidebar.

en	Add Agent Screen

en	Agents can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit an agent:

en	Click on an agent in the list of agents.

en	Edit Agent Screen

en	It is also possible to edit the agent personal preferences. To do this, click on the *Edit personal preferences for this agent* button in the left sidebar of the *Edit Agent* screen.

en	To find an agent:

en	Enter a search term to the search box in the left sidebar.

en	Click on the magnifying glass icon in the right part of the field or hit an ``Enter``.

en	If several agents are added to the system, use the search box to find a particular agent. Only the first 1000 agents are listed by default.

en	The agent permissions can be controlled by adding an agent to :doc:`groups` or :doc:`roles`. This can result a complex matrix of permissions. The effective permissions for an agent can be checked in the bottom of the *Edit Agent* screen. If roles (recommended) are used, this screen will reflect the combined permissions as dictated by the roles.

en	Effective Permissions for Agent Widget

en	Agent Settings

en	These are the default fields available for the internal database table.

en	Title or salutation

en	Some name prefix can be added here like *Mr.*, *Dr.*, *Jr.*, etc.

en	Firstname \*

en	The first name of the agent.

en	Lastname \*

en	The last name of the agent.

en	The agent display name can be set via the system configuration setting ``FirstnameLastnameOrder``. It may also show the user id, which is userful to be able to destiguish between agents with the same name.

en	The username of the agent to login to the system.

en	Password

en	The password of the agent. This will be auto-generated if left empty.

en	Email \*

en	The email address of the agent.

en	The email syntax and validity of an available MX record could prevent you from submitting this form. For some systems it may be acceptable to turn off these checks. See the :ref:`Agent Configuration Options`.

en	Mobile

en	The mobile phone number of the agent.

en	Agent Back End Sources

en	Agents can be read and synchronized from an Active Directory® or LDAP server.

en	The following configurations are taken care of by the *Customer Solution Team* in **OTOBO**. Please contact the *Customer Solution Team* via support@otrs.ch or in the `OTOBO Portal <https://portal.otrs.ch/>`__.

en	Agent Authentication Back End

en	The users table houses your agent data per default. You may attach a directory server (LDAP/Active Directory) to your installation for authentication. To achieve this copy the following block from the ``Defaults.pm`` and paste it into the ``Config.pm``.

en	The minimum required to connect to a directory server is:

en	``Host``

en	The DNS name or IP of your directory server.

en	``BaseDN``

en	The starting point in your directory tree.

en	``UID``

en	The attribute used for login and identification.

en	This is ``sAMAccountName`` for an Active Directory.

en	To use multiple back ends, add an additional section of the example code to the ``Config.pm``. Please make sure to add a numeric value [1-9] to all settings to indicate which settings belong to which back end.

en	All back ends will are used in succession. The UID must be unique to all back ends, otherwise some side effects may occur.

en	To synchronize with a specific directory server (see :ref:`Agent User Data` below), you must add the appropriate setting to your :ref:`Agent Authentication Back End`. To achieve this copy the following block from the ``Defaults.pm`` and paste it into the ``Config.pm``.

en	Reuse of an :ref:`Agent Synchronization Back End` is also possible.

en	Agent Synchronization Back End

en	It is advisable to synchronize the agent data so that agents need not be manually added to the users table prior to authorization. Additionally, groups and roles can be added automatically using security objects of the directory server.

en	Agent User Data

en	Syncing user data upon login. To achieve this copy the following block from the ``Defaults.pm`` and paste it into the ``Config.pm``.

en	Multiple :ref:`Agent Synchronization Back End` blocks can be used. Please make sure to add a numeric value [1-9] to all settings to indicate which settings belong to which back end. Each ``AuthSyncModule`` must be explicitly used in an :ref:`Agent Authentication Back End`.

en	Agent Group Data

en	It is possible to use security objects to synchronize users to OTOBO groups. To achieve this copy the following block from the ``Defaults.pm`` and paste it into the ``Config.pm``.

en	:doc:`groups` must be available in OTOBO to use this feature.

en	Agent Role Data

en	It is possible to use security objects to synchronize users to OTOBO roles. To achieve this copy the following block from the ``Defaults.pm`` and paste it into the ``Config.pm``.

en	:doc:`roles` must be available in OTOBO to use this feature.

en	Agent Configuration Options

en	Agents ↔ Groups

en	Efficient and straightforward management of permissions is essential in a growing business. Easy assignment of a particular user to a group for quick access, or to remove access, to resources is a must in every case.

en	The OTOBO interface provides you both with the possibility to manage an agent's access to one or more particular groups. As well, you can change multiple users access to any one group, efficiently and elegantly.

en	Use this screen to add one or more agents to one or more groups. To use this function, at least one agent and one group need to have been added to the system. The management screen is available in the *Agents ↔ Groups* module of the *Users, Groups & Roles* group.

en	Manage Agent-Group Relations

en	Manage Agents ↔ Groups Relations

en	To assign some groups to an agent:

en	Click on an agent in the *Agents* column.

en	Select the permissions you would like to connect the agent to groups with.

en	Change Group Relations for Agent

en	To assign some agents to a group:

en	Click on a group in the *Groups* column.

en	Select the permissions you would like to connect the group to agents with.

en	Change Agent Relations for Group

en	If several agents or groups are added to the system, use the filter box to find a particular agent or group by just typing the name to filter.

en	Multiple agents or groups can be assigned in both screens at the same time. Additionally clicking on an agent or clicking on a group in the relations screen will open the *Edit Agent* screen or the *Edit Group* screen accordingly.

en	Accessing an agent or a group provides no back link to the relations screen.

en	Agents ↔ Groups Relations Reference

en	When assigning an agent to a group or vice versa, several permissions can be set as connection between an agent and a group. The following permissions are available by default:

en	ro

en	Read only access to the ticket in this group/queue.

en	move_into

en	Permissions to move tickets into this group/queue.

en	create

en	Permissions to create tickets in this group/queue.

en	note

en	Permissions to add notes to tickets in this group/queue.

en	owner

en	Permissions to change the owner of tickets in this group/queue.

en	priority

en	Permissions to change the ticket priority in this group/queue.

en	chat_owner

en	Agents have full rights for a chat and can accept chat requests.

en	chat_participant

en	Agents may normally participate in a chat.

en	chat_observer

en	Agents may take part silently in a chat.

en	rw

en	Full read and write access to the tickets in this group/queue.

en	Not all available permissions are shown by default. See ``System::Permission`` setting for permissions that can be added. These additional permissions can be added:

en	stats

en	Gives access to the stats page.

en	bounce

en	Permissions to bounce an email message (with bounce button in *Ticket Zoom* screen).

en	compose

en	Permissions to compose an answer for a ticket.

en	customer

en	Permissions to change the customer of a ticket.

en	forward

en	Permissions to forward a message (with the forward button).

en	pending

en	Permissions to set a ticket to pending.

en	phone

en	Permissions to add a phone call to a ticket.

en	responsible

en	Permissions to change the responsible agent for a ticket.

en	By setting a checkbox in the header of a column will set all the checkboxes in the selected column. By setting the checkbox in the last *rw* column will set all the checkboxes in the selected row.

en	Agents ↔ Roles

en	As an organization grows, groups cannot be the denominator used for processing access rights. Roles become more and more a need because a role has a special set of permissions assigned. One mustn't give individual permissions, but the role carries the permissions built-in.

en	OTOBO allows easy access to a predefined set of permissions via one or more roles defined. These roles are assigned easily to one or more agents, or one or more agent to a role.

en	Use this screen to add one or more agents to one or more roles. To use this function, at least one agent and one role need to have been added to the system. The management screen is available in the *Agents ↔ Roles* module of the *Users, Groups & Roles* group.

en	Manage Agent-Role Relations

en	Manage Agents ↔ Roles Relations

en	To assign some roles to an agent:

en	Select the roles you would like to the agent belongs to.

en	Change Role Relations for Agent

en	To assign some agents to a role:

en	Click on a role in the *Roles* column.

en	Select the agents you would like to add to the role.

en	Change Agent Relations for Role

en	If several agents or roles are added to the system, use the filter box to find a particular agent or role by just typing the name to filter.

en	Multiple agents or roles can be assigned in both screens at the same time. Additionally clicking on an agent or clicking on a role in the relations screen will open the *Edit Agent* screen or the *Edit Role* screen accordingly.

en	Accessing an agent or a role provides no back link to the relations screen.

en	By setting the checkbox in the header of the column *Active* will set all the checkboxes in the column.

en	Customer Users

en	A record of who your company deals with requires more information about that individual: physical location for shipping and billing purposes, as well as contact information for email and phone contact.

en	OTOBO offers a great way to save individual information about contacts within organizations which your company serves. You can add as many personal connections into OTOBO as needed.

en	Use this screen to add a :term:`customer user` to the system. A fresh OTOBO installation contains no customer users by default. The customer user management screen is available in the *Customer Users* module of the *Users, Groups & Roles* group.

en	Customer User Management Screen

en	Manage Customer Users

en	A customer user can only be added to the system when at least one :term:`customer` exists. Create one or more :doc:`customers` first.

en	Adding or editing a customer user is possible only by using database back end. Using external directory services like LDAP will disable the customer user management functionality.

en	To add a customer user:

en	Click on the *Add Customer User* button in the left sidebar.

en	Add Customer User Screen

en	Customer users can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit a customer user:

en	Click on a customer user in the list of customer users.

en	Edit Customer User Screen

en	To find a customer user:

en	If several customer users are added to the system, use the search box to find a particular customer user. Only the first 1000 customer users are listed by default.

en	The customer user permissions can be controlled by adding a customer or a customer user to :doc:`groups`. This can result a complex matrix of permissions. The effective permissions for a customer user can be checked in the bottom of the *Edit Customer User* screen.

en	Effective Permissions for Customer User Widget

en	:doc:`customer-users-groups` needs to be enabled to use this feature.

en	Customer User Settings

en	The first name of the customer user.

en	The last name of the customer user.

en	The username of the customer user to login to the system.

en	The password of the customer user. This will be auto-generated if left empty.

en	The email address of the customer user.

en	CustomerID \*

en	The ID of the customer company the customer user belongs to. Select a customer from the list of :doc:`customers`.

en	Phone

en	The phone number of the customer user.

en	Fax

en	The fax number of the customer user.

en	The cellphone number of the customer user.

en	Street

en	The street name of the customer.

en	Zip

en	The zip code of the customer.

en	City

en	The headquarter city of the customer.

en	Country

en	The country of the customer user.

en	Valid \*

en	It is possible to assign multiple customers to customer users via the :doc:`customer-users-customers` screen.

en	Customer User Back Ends

en	The system works with many customer user data attributes such as username, email address, phone number, etc. These attributes are displayed in both the agent and the external interface, and also used for the authentication of customer users.

en	Customer data used or displayed within the system is highly customizable. The user login and the email address are always needed for customer authentication.

en	You can use two types of customer back end: database or LDAP. If you already have another customer back end (e.g. SAP), it is possible to write a module that uses it.

en	The administrator interface does not support the configuration of external back ends. Administrators need to edit the file ``Kernel/Config.pm`` by copying and pasting code snippets from ``Kernel/Config/Defaults.pm`` manually.

en	Do not modify the file ``Kernel/Config/Defaults.pm``, it will be overwritten after upgrading the system! Copy and paste the code snippets into ``Kernel/Config.pm`` instead.

en	Database

en	This is the default customer user back end for new installations. The example below shows the configuration of a database customer back end, which uses customer user data stored in the database table ``customer_user``.

en	If you want to customize the customer user data, change the columns or add new ones to the ``customer_user`` table in the database.

en	For example, to add a new field for room number:

en	Add a new column ``room`` to table ``customer_user``.

en	MySQL or MariaDB:

en	PostgreSQL (from the ``/opt/otobo`` directory):

en	Copy the ``$Self->{CustomerUser}`` section from ``Kernel/Config/Defaults.pm`` into ``Kernel/Config.pm``.

en	Add the new column to the ``Map`` array.

en	You can set the HTTP link target and link class (the last two keys) to ``undef`` in map array elements, if they are not to be used. These keys add ``target=""`` and ``class=""`` attributes to the HTTP link element, respectively. They are ignored if HTTP link is not set (it is ``''`` in this example).

en	It is recommended to always use English words for names.

en	Names can be translated into other languages with custom translation files. See the `Custom Translation File <http://doc.otobo.org/doc/manual/developer/7.0/en/content/how-it-works/translations.html#custom-translation-file>`__ chapter in the developer manual.

en	LDAP

en	If you have an LDAP directory with your customer user data, you can use it as the customer user back end. The example below shows the configuration of a LDAP customer user back end.

en	To activate and configure the LDAP back end:

en	Remove the comments (``#`` characters) from the beginning of the lines.

en	If additional customer user attributes are stored in your LDAP directory, such as a manager name, a mobile phone number, or a department, this information can be displayed in OTOBO.

en	To display additional customer user attributes from LDAP directory:

en	Expand the ``Map`` array in ``Kernel/Config.pm`` with the entries for these attributes.

en	Multiple Customer User Back Ends

en	If you want to use more than one customer user data source, the ``CustomerUser`` configuration parameter should be expanded with a number, like ``CustomerUser1`` and ``CustomerUser2``.

en	The following configuration example shows usage of both a database and an LDAP customer user back end.

en	It is possible to integrate up to 10 different customer back ends. Use the :doc:`customer-users` screen to view or edit (assuming write access is enabled) all customer user data.

en	Customer User Data in Dynamic Fields

en	Sometimes it can be useful to also store customer user data directly in dynamic fields of a ticket, for example to create special statistics on this data.

en	The dynamic field values are set, when a ticket is created or when the customer user of a ticket is changed. The values of the dynamic fields are taken from the customer user data. This works for all back ends, but is especially useful for LDAP back ends.

en	To activate this optional feature:

en	Activate the setting ``Ticket::EventModulePost###4100-DynamicFieldFromCustomerUser``.

en	Activate the setting ``DynamicFieldFromCustomerUser::Mapping``. This setting contains the configuration of which customer user field entry should be stored in which ticket dynamic field.

en	Create the dynamic fields, if the dynamic fields are not present in the system yet.

en	Enable the dynamic fields in setting ``Ticket::Frontend::AgentTicketFreeText###DynamicField``, so that they can be set manually.

en	The dynamic field must not be enabled in the following settings:

en	``Ticket::Frontend::AgentTicketPhone###DynamicField``

en	``Ticket::Frontend::AgentTicketEmail###DynamicField``

en	``Ticket::Frontend::AgentTicketCustomer###DynamicField``

en	If they were, they would have precedence over the automatically set values.

en	Customer Users ↔ Customers

en	In an organization, for example, which views its customers as it's departments and teams, a customer user may have to have access to multiple customers tickets for controlling purposes. Maybe you have partners who represent several different companies, or a corporation wants to have a look at all the requests of their subsidiaries.

en	For all situations, OTOBO provides the means. Aside from a primary customer, your customer users can gain access to multiple customer tickets as defined by you.

en	Use this screen to add one or more customer users to one or more customers. To use this function, at least one customer user and one customer need to have been added to the system. The management screen is available in the *Customer Users ↔ Customers* module of the *Users, Groups & Roles* group.

en	Manage Customer User-Customer Relations

en	Manage Customer Users ↔ Customers Relations

en	This module is for assigning a :term:`customer user` to additional :term:`customer` records. The primary customer is assigned via the :ref:`Customer User Settings`.

en	To assign some customers to a customer user:

en	Click on a customer user in the *Customer Users* column.

en	Select the customers you would like to assign to the customer user.

en	Change Customer Relations for Customer User

en	To assign some customer users to a customer:

en	Click on a customer in the *Customers* column.

en	Select the customer users you would like to assign to the customer.

en	Change Customer User Relations for Customer

en	If several customer users or customers are added to the system, use the search box to find a particular customer user or customer. Only the first 1000 customer users and customers are listed by default.

en	Multiple customer users or customers can be assigned in both screens at the same time. Additionally clicking on a customer user or clicking on a customer in the relations screen will open the *Edit Customer User* screen or the *Edit Customer* screen accordingly.

en	Accessing a customer user or a customer provides no back link to the relations screen.

en	By setting a checkbox in the header of a column will set all the checkboxes in the selected column.

en	Customer Users ↔ Groups

en	Customer users shouldn't need to be bothered with the internal workings of your service desk. A single point of contact request can trigger several processes within your organization, all of which having the customer user information attached and are visible to the customer.

en	OTOBO allows you to assign :term:`group` permissions to customer users. Access works just the same as for agents, preventing a customer from modifying and viewing a request. Thus allowing the customer to focus on the results of the original communication and funneling the discussion through one ticket.

en	Assign a group to an entire customer using :doc:`customers-groups`.

en	Use this screen to add one or more customer users to one or more groups. To use this function, at least one customer user and one group need to have been added to the system. The management screen is available in the *Customers Users ↔ Groups* module of the *Users, Groups & Roles* group.

en	Manage Customer User-Group Relations

en	Customer group support needs to be enabled in at least one customer user :term:`back end` to use this function. For the default OTOBO :term:`back end`, this can be enabled in the system configuration by clicking on the *Enable it here!* button.

en	Enable Customer Group Feature

en	To enable this feature in systems using a directory server or multiple non-default back ends, a custom configuration file needs to be placed in ``Kernel/Config/Files`` (for example named ``ZZZ_CustomerBackend.pm``). Once activated, all customer users from this back end will require group assignment.

en	After making changes to the back end, the server cache will be deleted, which may cause a temporary drop in performance.

en	Manage Customer Users ↔ Groups Relations

en	To assign some groups to a customer user:

en	Select the permissions you would like to connect the customer user to groups with.

en	Change Group Relations for Customer User

en	To assign some customer users to a group:

en	Select the permissions you would like to connect the group to customer users with.

en	Change Customer User Relations for Group

en	To change customer user default groups:

en	Click on the *Edit Customer User Default Groups* button in the left sidebar.

en	Add or modify groups in setting ``CustomerGroupAlwaysGroups``.

en	Deploy the modified system configurations.

en	CustomerGroupAlwaysGroups System Configuration Screen

en	``CustomerGroupAlwaysGroups`` System Configuration Screen

en	These groups are automatically assigned to all customer users.

en	If several customer users or groups are added to the system, use the search box to find a particular customer user or use the filter box to find a particular group by just typing the name to filter.

en	Multiple customer users or groups can be assigned in both screens at the same time. Additionally clicking on a customer user or clicking on a group in the relations screen will open the *Edit Customer User* screen or the *Edit Group* screen accordingly.

en	Accessing a customer user or a group provides no back link to the relations screen.

en	Customer Users ↔ Groups Relations Reference

en	When assigning a customer user to a group or vice versa, several permissions can be set as connection between a customer user and a group. The following permissions are available by default:

en	Read only access to the resource.

en	Full read and write access to the resource.

en	Customer Users ↔ Services

en	Use this screen to add one or more customer users to one or more services. To use this function, at least one customer user and one service need to have been added to the system. The management screen is available in the *Customers Users ↔ Services* module of the *Users, Groups & Roles* group.

en	Manage Customer User-Service Relations

en	Manage Customers Users ↔ Services Relations

en	To allocate some services to a customer user:

en	Select the services you would like to allocate to the customer user.

en	Change Service Relations for Customer User

en	To allocate some customer users to a service:

en	Click on a service in the *Services* column.

en	Select the customer users you would like to allocate to the service.

en	Change Customer User Relations for Service

en	If several customer users or services are added to the system, use the search box to find a particular customer user or use the filter box to find a particular service by just typing the name to filter.

en	Multiple customer users or services can be assigned in both screens at the same time. Additionally clicking on a customer user or clicking on a service in the relations screen will open the *Edit Customer User* screen or the *Edit Service* screen accordingly.

en	Accessing a customer user or a service provides no back link to the relations screen.

en	Manage Default Services

en	It is possible to add default services, so that all customer users may access them. This prevents having to add each service to each customer user.

en	To edit the default services:

en	Click on the *Edit default services* button in the left sidebar.

en	Select the services which should be selectable for all customer users.

en	Allocate Services to Customer User Screen

en	Mixing default services and customer specific services can be confusing. If a customer user has specific services assigned, then the default services will be not applied.

en	Customers

en	Use this screen to add customer companies to the system. A fresh OTOBO installation contains no customers by default. The customer management screen is available in the *Customers* module of the *Users, Groups & Roles* group.

en	Customer Management Screen

en	Manage Customers

en	Adding or editing a customer is possible only by using database back end. Using external directory services like LDAP will disable the customer management functionality.

en	To add a customer:

en	Click on the *Add Customer* button in the left sidebar.

en	Add Customer Screen

en	Customers can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit a customer:

en	Click on a customer in the list of customers.

en	Edit Customer Screen

en	To find a customer:

en	If several customers are added to the system, use the search box to find a particular customer. Only the first 1000 customers are listed by default.

en	Customer Settings

en	Customer ID \*

en	The internal name of the customer. Should contain only letters, numbers and some special characters.

en	Customer \*

en	Any type of characters can be entered to this field including uppercase letters and spaces. The name of this resource. The name will be displayed in the overview table.

en	The country of the customer. Choose a country from the list.

en	URL

en	The web page or other URL of the customer.

en	Customers ↔ Groups

en	Your organization grows, and it's not practical at some point to assign permissions to individual users, you need to assign the permissions to all customer users of a customer.

en	OTOBO allows you to assign :term:`group` permissions to a :term:`customer`. Access works just the same as for agents, preventing a customer from modifying and viewing a request. Thus allowing the customer to focus on the results of the original communication and funneling the discussion through one ticket.

en	Assign a single customer user to a group using :doc:`customer-users-groups`.

en	Use this screen to add one or more customers to one or more groups. To use this function, at least one customer and one group need to have been added to the system. The management screen is available in the *Customers ↔ Groups* module of the *Users, Groups & Roles* group.

en	Manage Customer-Group Relations

en	Manage Customers ↔ Groups Relations

en	To be able to use this feature, you have to activate its setting first.

en	Enable Customer-Group Support

en	To assign some groups to a customer:

en	Select the permissions you would like to connect the customer to groups with.

en	Change Group Relations for Customer

en	To assign some customers to a group:

en	Select the permissions you would like to connect the group to customers with.

en	Change Customer Relations for Group

en	To change customer default groups:

en	Click on the *Edit Customer Default Groups* button in the left sidebar.

en	Add or modify groups in setting ``CustomerGroupCompanyAlwaysGroups``.

en	CustomerGroupCompanyAlwaysGroups System Configuration Screen

en	``CustomerGroupCompanyAlwaysGroups`` System Configuration Screen

en	These groups are automatically assigned to all customers.

en	If several customers or groups are added to the system, use the search box to find a particular customer or use the filter box to find a particular group by just typing the name to filter.

en	Multiple customers or groups can be assigned in both screens at the same time. Additionally clicking on a customer or clicking on a group in the relations will open the *Edit Customer* screen or the *Edit Group* screen accordingly.

en	Accessing a customer or a group provides no back link to the relations screen.

en	Customers ↔ Groups Relations Reference

en	When assigning a customer to a group or vice versa, several permissions can be set as connection between a customer and a group. The following permissions are available by default:

en	Same Customer

en	Gives customer users group based access to tickets from customer users of the same customer (ticket ``CustomerID`` is a ``CustomerID`` of the customer user).

en	Groups

en	Use this screen to add groups to the system. A fresh OTOBO installation contains some default groups. The group management screen is available in the *Groups* module of the *Users, Groups & Roles* group.

en	Group Management Screen

en	Manage Groups

en	To add a group:

en	Click on the *Add Group* button in the left sidebar.

en	Add Group Screen

en	Groups can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit a group:

en	Click on a group in the list of groups.

en	Edit Group Screen

en	If several groups are added to the system, use the filter box to find a particular group by just typing the name to filter.

en	Group Settings

en	Renaming a group does not affect permissions previously given. When *group1* is now called *group2*, then all the permissions are the same for the users which used to be assigned to *group1*. This result is because OTOBO uses IDs for the relationship, and not the name.

en	Invalidating a group does not remove the permissions from the user, but only makes them invalid. If you reactivate this group, even with a new name, the permissions take effect.

en	Default Groups

en	Every agent's account should belong to at least one group or role. In a fresh installation, there are some pre-defined groups available:

en	``admin``

en	Allowed to perform administrative tasks in the system.

en	``stats``

en	Qualified to access the stats module of OTOBO and generate statistics.

en	``users``

en	Agents should belong to this group, with read and write permissions. They can then access all functions of the ticket system.

en	Roles

en	Use this screen to add roles to the system. A fresh OTOBO installation contains no roles by default. The role management screen is available in the *Roles* module of the *Users, Groups & Roles* group.

en	Role Management Screen

en	Manage Roles

en	To add a role:

en	Click on the *Add Role* button in the left sidebar.

en	Add Role Screen

en	Roles can not be deleted from the system. They can only be deactivated by setting the *Validity* option to *invalid* or *invalid-temporarily*.

en	To edit a role:

en	Click on a role in the list of roles.

en	Edit Role Screen

en	If several roles are added to the system, use the filter box to find a particular role by just typing the name to filter.

en	Role Settings

en	Roles ↔ Groups

en	Use this screen to add one or more roles to one or more groups. To use this function, at least one role and one group need to have been added to the system. The management screen is available in the *Roles ↔ Groups* module of the *Users, Groups & Roles* group.

en	Manage Role-Group Relations

en	Manage Roles ↔ Groups Relations

en	To assign some groups to a role:

en	Select the permissions you would like to connect the role to groups with.

en	Change Group Relations for Role

en	To assign some roles to a group:

en	Select the permissions you would like to connect the group to roles with.

en	Change Role Relations for Group

en	If several roles or groups are added to the system, use the filter box to find a particular role or group by just typing the name to filter.

en	Multiple roles or groups can be assigned in both screens at the same time. Additionally clicking on a role or clicking on a group in the relations screen will open the *Edit Role* screen or the *Edit Group* screen accordingly.

en	Accessing a role or a group provides no back link to the relations screen.

en	Roles ↔ Groups Relations Reference

en	When assigning a role to a group or vice versa, several permissions can be set as connection between a role and a group. The following permissions are available by default:

en	Users with this permission type will only be able to observe chats in a channel after they have been invited.

en	Users with this permission type will be able to take part in a chat, but only after they get invited to it.

en	Users with this permission type will be able to accept chat customer/public requests and do all kinds of observer and participant actions on a chat.

en	Glossary

en	Activity

en	Part of the process management.

en	Agent

en	An agent is a user which services customer users. The person working for your organization.

en	Back end

en	A configuration file, module, script or other functional item within OTOBO which is not reachable via the browser.

en	Defines working hours, time-zone, and holidays to be applied when using :term:`escalation times`.

en	Customer

en	Physical organizations to which customer users are assigned. These provide the function to group users together which belong to a single organization.

en	Customer User

en	Physical persons, and their contact data, which belong to a customer. These are the people raising tickets.

en	Dynamic Field

en	A field used in tickets and articles to extend the data which can be saved in a ticket or article. They are saved from values in the database or accessed from outside resources.

en	Escalation Times

en	The defined amount of working time before a ticket breaches an agreement.

en	Front end

en	The graphical interface to OTOBO as viewed in a browser.

en	Group

en	This is a resource within OTOBO. An :term:`agent` or a :term:`customer` can be assigned permissions to this resource as needed. Additionally, they can be used for access control, processes and web services.

en	Invoker

en	An invoker is a special Perl module which allows OTOBO to provide information to a remote system via REST or HTTP. Invokers must be developed in Perl by a back end developer.

en	Mapping

en	A mapping allows OTOBO to provide inbound and outbound translation of data allowing us to offer a specific data construction to rebuild incoming structures to meet our needs.

en	Operation

en	Similar to a web hook, a provider operation offers a specific sub-set of OTOBO Perl API functionality to external systems.

en	Process

en	Part of the process management. A process defines the workflow for a task and consists of activities, activity dialogs, transitions and transition actions.

en	Part of OTOBO to support definition of workflows for recurring tasks.

en	Process Path

en	Part of the process management. A process path describes the connections between the parts of a process.

en	A resource is any object which has effective permissions. This can be, but is not limited to, a ticket, dashboard widget, statistic, or module.

en	Screen

en	A graphical interface to OTOBO viewed in a browser (see also :term:`Front end`).

en	A means of delivering added value to customers by making it easier for customers or helping them to achieve their desired results without them having to personally bear the responsibility for specific costs and risks.

en	Service Level Agreement

en	A service level agreement (SLA) is a contract between a service provider (either internal or external) and the end user that defines the level of service expected from the service provider. SLAs are output-based in that their purpose is specifically to define what the customer will receive.

en	Service Request

en	(see also :term:`Ticket`).

en	Transition

en	Transition Action

en	SLA

en	(see also :term:`Service Level Agreement`).

en	A ticket is a collection of all communications with a customer during the course of a service request. A ticket contains articles, which are the communication received from or sent to customers, agents, external systems, etc. Tickets belong to a customer user, are assigned to agents and reside in queues.

en	Transport

en	A transport is the method chosen for communication. OTOBO supports REST and SOAP.

en	Activity Dialog

en	Working Time

en	A definition of minutes passed during the defined working hours of any :term:`calendar`.

en	Documentation History

en	1.) 2019 - OTRS Administration Manual - OTRS AG (https://otrs.com)

en	2.) 2020 - OTOBO Administration Manual - Rother OSS GmbH (https://otobo.de)

en	Published by: Rother OSS GmbH, (https://otobo.de), Oberwalting 31, 94339 Leiblfing, Germany. Authors: OTRS AG (original version), Rother OSS GmbH (https://otobo.de)

en	Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found on the `GNU website <https://www.gnu.org/licenses/fdl-1.3.txt>`__.

en	How-Tos

en	While this documentation serves as a reference, it does not directly provide solutions or give recipes for common configurations. For this purpose have a look at these resources:

en	https://portal.rother-oss.com/otobo/public.pl

en	OTOBO Administration Manual

en	This is the OTOBO Administration Manual. It serves as a reference to help administrators manage and configure the OTOBO system effectively.

en	This work is copyrighted by OTRS AG (https://otrs.com), Zimmersmühlenweg 11, 61440 Oberursel, Germany.

en	Copyright © for modifications and amendments 2019-2024 ROTHER OSS GmbH (https://otobo.de), Oberwalting 31, 94339 Leiblfing, Germany

en	Terms and Conditions OTRS: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found on the GNU website.

en	Terms and Conditions Rother OSS: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "COPYING".

en	Published by: Rother OSS GmbH, (https://otobo.de), Oberwalting 31, 94339 Leiblfing, Germany.

en	Authors: OTRS AG (original version), Rother OSS GmbH (https://otobo.de).