Customer User Self-Administration

Shawn Beasley26. Nov 2019 | ConsultingDevelopmentUse cases


The practical examples presented in our technical blog ( and now in the expert category in our FAQ blog section serve as a source of ideas and documentation to show what is theoretically possible with OTRS in concrete scenarios or sometimes even for more exotic configurations. All configurations presented here were developed under laboratory conditions as a proof of concept. 

We can only guarantee testing and implementation of these concepts to be error-free and productive if implemented in a workshop with one of our OTRS consultants. Without this, the responsibility lies with the customer himself. Please note that configurations from older OTRS versions may not work in the newer ones.

In past articles we’ve talked about process management and web services. Combining these two can make for interesting new features, without the need for new development. For example, OTRS doesn’t offer a solution to let customers administer their own customer users by default. Combining process management with web services, however, can allow you to add such a feature to your installation.

Just gimme the core message.

Using OTRS and the OTRS feature add-on ticket invoker, you can create a user-driven RPC-backed process to allow customer users to create and register their own customer users.


Process Map



Above you see a process which allows the customer user to enter customer user details (dynamic fields). The process will then trigger the Generic::RPC (see Remote Administration per REST.) To call the Kernel::System::CustomerUser::CustomerUserAdd and create the customer.

If any error occurs, the ticket will be closed and the process will end. If not, the process ticket is closed successfully.

When a customer user leaves the company, the customer user administrator can easily find the closed tickets and remove the user by using the customer user maintenance activity. The customer user is then marked for removal and Kernel::System::CustomerUser::CustomerUserUpdate will set the user to invalid.

The web service setup is trivial and requires some mapping.

Web Service Details

Elements to be mapped for use with the Generic::RPC as follows:
        Source         => Hard Coded
        ID             => Mapped from DynamicField_UserLogin
        UserFirstname  => Mapped from DynamicField_UserFirstname
        UserLastname   => Mapped from DynamicField_UserLastname
        UserCustomerID => Mapped from current customer
        UserLogin      => Mapped from DynamicField_UserLogin
        UserEmail      => Mapped from DynamicField_UserEmail
        ValidID        => Mapped from DynamicField_ValidState
        UserID         => Mapped from current user
Outgoing data from the Ticket to the Generic::RPC operation will be mapped and return data for error handling.
Outbound Mapping AddUser
<?xml version="1.0" encoding="UTF-8"?> <xsl:transform version="1.0" xmlns:xsl=""> <xsl:output method="xml" encoding="utf-8" indent="yes" /> <!-- Don't return unmatched tags --> <xsl:template match="text()"/> <!-- Root template -->
    <xsl:template match="/">
                <UserLogin><xsl:value-of select="//Ticket/DynamicField[Name = 'UserLogin']/Value"/></UserLogin>
                <UserFirstname><xsl:value-of select="//Ticket/DynamicField[Name = 'UserFirstname']/Value"/></UserFirstname>
                <UserLastname><xsl:value-of select="//Ticket/DynamicField[Name = 'UserLastname']/Value"/></UserLastname>
                <UserEmail><xsl:value-of select="//Ticket/DynamicField[Name = 'UserEmail']/Value"/></UserEmail>
                <UserCustomerID><xsl:value-of select="//Ticket/CustomerID"/></UserCustomerID>
                <ValidID><xsl:value-of select="//Ticket/DynamicField[Name = 'ValidState']/Value"/></ValidID>
Inbound Mapping AddUser (error handling)
<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform version="1.0" xmlns:xsl="">
    <xsl:output method="xml" encoding="utf-8" indent="yes" />
    <xsl:template match="/RootElement">
            <xsl:when test="not(Result)">
                        <State>closed unsuccessful</State>
Problems and Considerations
  1. A customer user will never know why a user couldn’t be created. Any error should be reported to the OTRS admin. Generally, it’s related to a duplicate UserLogin. It could also be a bad or duplicate UserEmail.
  2. Any customer can create a user for his company.
  1. To help customer users understand what’s happening, a status can be added, the ticket closed, and a note to “contact the admin of the system for more details” can be created.
  2. Use the ACL to limit the process to a specific user or users.
  3. Company tickets can be limited to only specific users.
Dynamic Fields Needed for Mapping

Name:  UserLastname
Label:  User Last Name
Type:   Text
Object: Ticket

Name:   UserFirstname
Label:    User First Name
Type:    Text
Object: Ticket

Name:   UserLogin
Label:   User Login
Type:    Text
Object: Ticket

Name:   UserEmail
Label:    User Email
Type:     Text
Object:  Ticket

Name:   ValidState
Label:    User Valid
Type:     Dropdown
Object:  Ticket

Name:   ReqestResponse
Label:    Request Response
Type:     Text
Object:  Ticket


Need assistance? Contact

Summary (TL/DR)

Some missing features can be built using a loopback request to OTRS’ internal Perl API. Using processes to control these gives you even more power.

Jens Bothe at 11.12.2020, 08:05

Please contact our sales team for commercial support

Prabhu at 21.09.2020, 13:23

We planned to implement a new category called the "location" to take better report for location wise. Kindly suggest how to add that field in otrs ticket version 6.

satyadeva at 15.01.2020, 04:48

Nice article thank you so much sir for sharing your knowledge and ideas Prosthesis

Your email address will not be published. Required fields are marked *