This chapter describes the features of OTRS Help Desk (OTRS). You will find information about the hardware and software requirements for OTRS. Additionally, in this chapter you will learn how to get commercial support for OTRS, should you require it, and how to contact the community.
OTRS Help Desk (OTRS) is a web application that is installed on a web server and can be used with a web browser.
OTRS is separated into several components. The main component is the OTRS framework which contains all central functions for the application and the ticket system. It is possible to install additional applications such as OTRS::ITSM modules, integrations with Network Monitoring solutions, a knowledge base (FAQ), et cetera.
OTRS has many features. The following list gives an overview of the main features included in the OTRS framework.
OTRS comes with separate, modern web interfaces for agents and customers.
It can be used on any modern web browser, including mobile platforms and is retina ready.
The web interface can be customized with own themes and skins.
Powerful and customizable agent dashboard with personal ticket overviews and graphical statistics support.
An extensible reporting engine provides various statistics and report scheduling options.
With the ProcessManagement it is possible to define own ticket-based screens and processes (ticket workflows).
OTRS has a built-in rights management that can be extended with fine-grained access control lists (ACLs).
Support for more than 30 languages and different time zones.
Support for MIME emails with attachments.
Automatic conversion of HTML into plain text messages (increased security for sensitive content and enables faster searching).
Incoming mail can be filtered and pre-processed with complex rules, e.g. for spam messages or Queue distribution.
Support for PGP and S/MIME standards for key/certificate management and email processing.
Automatic responses, configurable for every queue.
Email notifications for agents about new tickets, follow-ups or unlocked tickets.
It is possible to define an own Ticket identifier to recognize follow-ups, e.g. Call#, Ticket# or Request#. There are different ticket number generators (date-based, random etc.) and you can integrate your own as well. Follow-ups can also be recognized by In-Reference-To headers or external ticket numbers.
OTRS uses Tickets to gather all external an internal communication that belongs together. These tickets are organized in Queues.
There are many different ways of looking at the tickets in a system (based on Queues, Status, Escalation etc.) in different level of detail (small/medium/preview).
The Ticket history records all changes to a ticket.
Tickets can be changed in many ways, such as replying, forwarding, bouncing, moving to another Queue, updating attributes (state, priority etc.), locking and accounting working time. It is possible to modify many tickets at once (bulk action).
Pending time and escalation time / SLA management allow time-based scheduling and restrictions on tickets.
Tickets can be linked to other tickets or other objects such as FAQ entries.
Automatic and timed actions on tickets are possible with the "GenericAgent".
OTRS comes with a powerful search engine that allows complex and fulltext searches on tickets.
OTRS runs on many operating systems (Linux, Solaris, AIX, FreeBSD, OpenBSD, Mac OS 10.x) and supports several database systems for the central OTRS back-end (MySQL, PostgreSQL, Oracle, MSSQL).
The core system can be extended by installing OTRS packages. There are many free packages (such as FAQ, OTRS::ITSM and others) as well as FeatureAddon packages that are available for service contract customers of the OTRS group.
Integration of external back-ends for the customer data, e.g. via AD, eDirectory or OpenLDAP. Customers can authenticate via database, LDAP, HTTPAuth or Radius.
With the GenericInterface it is easy to connect OTRS to other web services. Simple web services can be integrated without programming, complex scenarios with custom extensions. The OTRS Ticket connector allows the creation, updating and searching of tickets, via web services from a third party application.
Now let us look at the changes in recent versions of OTRS.
Implemented proper time zone support. Time zones can be configured system wide and also on a per-user basis.
Improvements to ticket handling
Added possibility to store unfinished ticket forms as drafts for later reuse.
Completely revamped ticket zoom screen, with a fresh new design with accent on content. User avatars have been introduced as a visual aid for easier identification of the article sender. Article display settings are now displayed in a settings dialog.
Dropped dubious and somewhat confusing article types, and introduced the concept of communication channels as source for ticket articles (e.g. Email, Phone, Chat, etc). Customer visibility of articles can now be determined by a simple check-box.
Improved AgentTicketHistory screen usability.
Merged the add-on module OTRSAdvancedTicketSplit. Now it's possible to select to which kind of ticket an article should be split: phone (default), email or process ticket. For process tickets, additional selection of specific process will be provided. However, only those fields which are configured in the first activity dialog will be adopted from original ticket.
Added support for ticket number and title search in ticket merge and bulk screens. Auto-complete list can be used to populate the ticket number field with a single click, therefore speeding up the process and limiting room for error. In the ticket merge screen, there is also a CustomeriD search filter option, which will limit the results to tickets belonging to the same customer company as the source ticket.
Split last sender and ticket title columns in ticket overviews.
It's now possible to access all supported article actions directly from large ticket overview screen.
It is now possible to delete linked objects directly from the zoom view.
Ticket search and statistic can now filter for pending until time.
Added possibility to restrict zoom and print screens in the customer interface by using ACLs.
The used search template is now shown on the ticket search result screen.
Added possibility to automatically lock new tickets to the agent who creates them.
Added possibility to send notifications to the agent who created a ticket, thanks to Dian Tong Software.
Added new recipient notification groups 'AllRecipientsFirstArticle' and 'AllRecipientsLastArticle'.
Make it possible to configure which ticket state types to show striked through in the linked objects table, thanks to Renée Bäcker.
Made possible to define ServiceIDs and SLAIDs as default shown ticket search attributes, thanks to Paweł Bogusławski.
Merged the add-on module OTRSTicketCloseRedirect. It is now possible by a new SysConfig setting to stay in Ticket Zoom after an action that closes the ticket instead of been redirected to the last overview screen or dashboard. This is now controlled by the new SysConfig setting "Ticket::Frontend::RedirectAfterCloseDisabled".
Merged the add-on module OTRSUserDefaultQueue, With a new SysConfig setting now it is possible to pre-select a queue to create a ticket in the New Phone, Email and Process ticket screens.
Merged the add-on module OTRSAppointmentCalendar. Now OTRS provides a calendar implementation that allows agents to manage and display multiple calendars and their appointments.
Improvements for working with customers
Added dynamic field support for customer users and customers. This makes it possible to attach additional data fields to customer users and customers (companies) without making manual changes to the database.
Modernized the OTRS address book. It is now possible to search for all configured custom user and customer fields.
Added the Customer User Information Center frontend. This works like the existing Customer Information Center, but focuses on all data of one particular customer user, rather than a complete customer (company).
Improved the selection of customers in various screens by adding autocomplete fields.
Added support for proper Chinese name formatting, thanks to Dian Tong Software.
Removed custom spell-checker in favor of using the built-in spell checker features of the different browsers.
Email articles now support display of their transmission status in the agent zoom screen. Messages with errors will be flagged as such, and automatic notifications will be triggered for relevant agents. Useful email resend screen can be used to resend failed messages.
Added option for dashboard widgets to mark them as mandatory. With this feature administrators have the ability to configure dashboard widgets that can't be disabled by the agents individually.
Added the possibility to filter content of the CCI Dashboard Widget.
Added beautiful drag & drop multi file upload for agent and customer interface.
Added a high contrast skin for visually impaired agents.
Improved session storage to no longer include permission information. This should result in significant performance gains for large systems with many agents and groups.
Moved ticket number counter from the TicketCounter.log file to the database. This allows OTRS to process incoming e-mails much faster and in parallel.
Improved web upload cache performance, thanks to Paweł Bogusławski.
Improved Generic Agent performance at deleting old execution times. Thanks to Moritz Lenz @ noris networks!
Made bcrypt cost configurable for agent and customer password hashing, thanks to Paweł Bogusławski.
Web service improvements
Added support for additional response headers in REST and SOAP provider configuration.
Added possibility to filter for events before calling Invokers.
Added the possibility to include the ticket data in web service response data.
Added automatic cleanup of old web service debug log information.
Added new operations TicketHistoryGet and SessionGet.
Updated default web service configurations.
Improved Authentication, Proxy and SSL handling in SOAP and REST transport.
Improved usability of debugger.
Added SOAPAction naming flexibility.
Improved SOAP output generation.
Prevent usage of invalid web services in provider.
Globally changed wording from 'webservice' to 'web service'.
Added error handling to the Generic Interface.
Improved XSLT mapping functionality.
Added possibility to configure default headers for outgoing emails (Sendmail::DefaultHeaders), thanks to Renée Bäcker.
Added possibility to use multiple named captures in Postmaster filters, thanks to Renée Bäcker.
Added possibility to set the ticket title in Postmaster filters, thanks to Renée Bäcker.
Add support for setting owner and responsible via filter also for follow-ups, thanks to Renée Bäcker.
Make it possible to re-enable auto responses from Postmaster filters by setting X-OTRS-Loop to no/false, thanks to Paweł Bogusławski.
All email communication is now being queued for sending and handled by dedicated scheduled daemon task. In case of errors, multiple retries will be scheduled, in order to alleviate temporary problems.
Added possibility to add an external link to the action menu in AgentTicketZoom, thanks to Paweł Bogusławski.
Renewed system configuration mechanism including a totally new graphical user interface.
Added possibility to review changes before they are effective.
Exclusively edit settings, so other administrators can not change the same setting at the same time.
Added possibility to define favorite settings for quick access.
Added new console commands to display and update setting values (Maint::Config::Dump and Maint::Config::Rebuild).
Added possibility to distribute configuration states to all nodes in a cluster environment.
Added new command Admin::Package::UpgradeAll, which allows updating all installed packages at once. This can also be triggered from the package manager screen.
Renewed main administration screen.
Renewed user preferences screen.
Added SHA-512 as new password digest method to agent and customer authentication.
Added support for multi-tiered customer and customer user relationships.
Added the possibility to use the auto complete search for the customer ID selection in the user management frontend.
Improved command Maint::Ticket::InvalidUserCleanup. It can now now both unlock tickets of invalid users and also (optionally) change their state to make sure they will not be overlooked. Thanks to Moritz Lenz @ noris networks!
Added per-address email loop protection configuration (PostmasterMaxEmailsPerAddress), thanks to Moritz Lenz.
Added console command to list configured queues, thanks to Martin Burggraf.
Added completely new log mechanism for email communications. The dashboard-like display allows administrators to quickly see what might be wrong in their system regarding receiving and sending emails. Account overview can be used to determine which mail accounts might be having issues and why. Detailed logging should help figuring out how an email was processed by the system before ending up in a specific ticket.
OTRS is now optimized for use on different types and sizes of mobile devices.
Single-select and multi-select input fields have been modernized and provide advanced searching and filtering capabilities (thanks to Dusan Vuckovic at Mühlbauer).
Images can now be added/uploaded to the WYSIWYG editor using Copy&Paste and Drag&Drop from anywhere outside the application (in all browsers, without additional Add-On).
Improved ticket notification system. It is now possible to configure own ticket notifications with own trigger conditions and recipients. With OTRS Business Solution™, notifications can also be delivered via SMS and/or Notification Web View. The latter is a special screen in OTRS that holds all notifications of the agent; with this OTRS can be used entirely without an email client.
Statistics received a new graphical user interface which is much better accessible and helps to create great statistics quickly and easily.
Additionally, statistics support the new time periods “quarter” and “half-year”
It is now possible to group action menu items in the ticket zoom screen. Less often used items can be grouped in a submenu, improving screen usage and clarity.
Ticket overviews can now display customer company data, thanks to Renée Bäcker.
The ticket process TransitionAction “TicketCreate” can now create tickets without articles.
The new OTRS Daemon handles all asynchronous and periodic tasks and replaces all previous OTRS cron jobs. In a clustered environment the load is automatically distributed over the nodes.
It is now possible to specify multiple readonly mirror (slave) databases for expensive computations such as statistics or fulltext searches to distribute the load among these database servers.
A new two-factor authentication layer allows added login security.
If entering a fixed username and password doesn’t satisfy your requirements, you can now additionally use the open standard for time based one-time passwords (RfC 6238, also known as Google Authenticator).
After having enabled the two-factor authentication, agents and customers can add a shared secret to their preferences and immediately start logging in using one-time passwords created by a compatible method of their choice (e.g. the Android Google Authenticator app).
A new XSLT based GenericInterface mapping module allows for arbitrarily complex user-defined data mapping.
The new OTRS console makes working on the commandline easy and fun. All commands have a consistent interface, useful documentation and provide helpful colored output.
Administrators can now specify a minimum log level to reduce logging volume, thanks to Renée Bäcker.
Overview screens in the admin area now show invalid entities in gray, making it easy to focus on active elements.
A new cleaner flat design has been implemented.
Agents can now reply directly to a ticket note. The original notes body is quoted in the new note.
Agents can now make use of templates in all screens with internal notes.
Ticket action screens (such as note, owner etc.) now allow to do actions without always creating an article (configurable).
New ticket overview based on "my services" that an agent can subscribe to. Notification options for new tickets and follow-ups can now be based on "my queues", "my services" or combinations of both.
OTRS can now display tickets with thousands of articles.
Customer online list in Dashboard now links directly to CustomerInformationCenter page for the customer.
Agents can now persistently reorder their main menu with drag&drop.
Agents and customers can now search tickets by attachment name.
New Dashboard Widget for running process tickets.
New search options for the last change time of the ticket.
Added new screen for outgoing emails on a ticket that are not replies.
OTRS 4 can handle more concurrent users/requests on the same hardware, and response times for single requests are shorter as well, especially for pages with lots of data.
The GenericInterface now also supports HTTP REST as network transport protocol.
Postmaster filters are no longer limited to 4 match/set fields. They can now have a configurable amount of fields (default 12, up to 99).
A new configuration option Ticket::MergeDynamicFields makes it possible to specify which dynamic fields should also be merged when a ticket is merged to another ticket.
Added new options to check dynamic fields of type text on patterns relating to error messages (translated), if they do not match.
Added new options to restrict dynamic fields of type date/datetime on future or past dates.
OTRS can be configured to automatically unlock a ticket if articles are added and the owner is out of office.
Linked tickets of a specific type (e.g. merged or removed) can now be hidden via SysConfig option.
ACL handling has been improved, made more consistent and easier to debug.
Added new ACL option PossibleAdd to add items to a possible list without resetting (like Possible does).
Added new ACL value modifiers [Not], [NotRegExp], [Notregexp], for all ACLs parts.
Process handling has been improved, made more consistent and easier to debug.
A new GUID-based entity naming scheme for the OTRS Process configuration makes it possible to safely transfer processes from one system to another without duplicating the entities.
Added new Transition Action to create a new ticket.
Added possibility to define variable Transition Action attributes based on current process ticket values.
The possibility to schedule System Maintenance periods is available from the System Administration panel in the Admin interface.
A notification about an incoming System Maintenance period will be shown with some (configurable) time in advance.
If a System Maintenance is active, a notification about it will be shown on the Agent and Customer interface, and only admin users can log on to the system.
An overview screen informs admins about active sessions, which can be ended all on one click or one by one.
Added possibility to disable sysconfig import via configuration.
Added Apache MD5 as a new password hashing backend, thanks to Norihiro Tanaka.
Added the possibility to restrict customer self registration by email address whitelist or blacklist, thanks to Renée Bäcker.
Added new dashboard module that shows the output of an external command, thanks to ib.pl.
New powerful template engine based on Template::Toolkit.
A central object manager makes creating and using global objects much easier (thanks to Moritz Lenz @ noris network).
The OPM package format was extended to signal that a package has been merged into another package, allowing the package manager to correctly handle this situation on package installation or update.
Caching was centralized in one global cache object which also performs in-memory caching for all data.
Added cache benchmark script, thanks to ib.pl.
OTRS can be installed on many different operating systems. OTRS can run on linux and on other unix derivates (e.g. OpenBSD or FreeBSD). OTRS does not have excessive hardware requirements. We recommend using a machine with at least a 3 GHz Xeon or comparable CPU, 8 GB RAM, and a 256 GB hard drive.
To run OTRS, you'll also need to use a web server and a database server. Apart from that, you should install perl and/or install some additional perl modules on the OTRS machine. The web server and Perl must be installed on the same machine as OTRS. The database back-end may be installed locally or on another host.
For the web server, we recommend using the Apache HTTP Server, because its module mod_perl greatly improves the performance of OTRS. Apart from that, OTRS should run on any web server that can execute Perl scripts.
You can deploy OTRS on different databases. You can choose between MySQL, PostgreSQL or Oracle. If you use MySQL or PostgreSQL you have the advantage that the database and some system settings can be configured during the installation, through a web front-end.
For Perl, you will need some additional modules which can be installed either with the Perl shell and CPAN, or via the package manager of your operating system (rpm, yast, apt-get).
Apache2 + mod_perl2 or higher (recommended)
Webserver with CGI support (CGI is not recommended)
MySQL 5.0 or higher (MySQL 8+ is not supported)
PostgreSQL 9.2 or higher
Oracle 10g or higher
The section in the manual about installation of Perl modules describes in more detail how you can set up those which are needed for OTRS.
If you install a binary package of OTRS, which was built for your operating system (rpm), either the package contains all Perl modules needed or the package manager of your system should take care of the dependencies of the Perl modules needed.
Firefox version 31 and higher
Safari version 6 and higher
Internet Explorer version 11
OTRS 9 will not support Internet Explorer anymore.
Znuny and the ((OTRS)) Community Edition have a large user community. Users and developers discuss and exchange information on related issues through the forum and Discord. You can use these channels to discuss installation, configuration, usage, localization and development of Znuny. You can report software bugs in our bug tracking system.
The homepage of the Znuny community is: http://www.znuny.org/.
We offer best professional support from the Znuny team, reliable Znuny security and regular free updates as well as an large set of additional add-ons that you can flexibly activate or deactivate according to different deployment scenarios.