OTRS Config Part II: A Sample Workflow


This post builds on OTRS Config Part 1. If you ended up here first somehow, you might want to go back and check that one out first. This is a more grounded, concrete example of the high-level ideas introduced in that post. Hopefully it brings a lot of that stuff home. And there’s more in Part 3, if you’re the kind of person who likes to skip ahead.

Scope of Application

The descriptions and screenshots in this document were generated for and from a Linux system with the following setup:

  • CentOS 6.4 or 6.5 | OpenSuSE 13.1
  • MySQL 5.1.71
  • OTRS 3.3.3 | OTRS 3.3.4
  • Apache 2.2.15 (Unix)
  • Viewed with Firefox 26

You might want to install a similar setup to follow along. But you can do all the same things on a Windows or Mac.

An OTRS Workflow

Below I have built on the abstract workflow included in the previous post. In this example, a user sends in a request for help installing a new printer. Review the workflow carefully. Try to answer the following questions:

  • What Queues, Groups, and Roles will we need?
    • Hint: The “Printer” Queue is a Sub-Queue of the “Hardware” Queue
  • What rights do the techs in the respective Roles need to the Queues


By my count, we need the following:

  • Queues
    • Unassigned
    • Hardware
    • Printer, as a Sub-Queue of Hardware
    • QA[1]
  • Groups
    • Tier 1
    • Tier 2
  • Roles
    • Tier 1
    • Tier 2[2]

As we discussed before, when you create a Queue in OTRS, you must associate it with a Group, so we’ll start by creating our Groups.

Create a Group

Log into OTRS and go to the Admin interface. Under Agent Management, you will find a link to the Group Management interface.


When you click it, you’ll first see a list of existing Groups. In a fresh installation, there will be only three: admin, stats, and users. If you have installed additional modules, such as the FAQ, there will be more. We’re going to create a new one called “Tier 1 Group” by clicking the Add Group button on the left.


It really couldn’t be any easier. There’s one required field: Name.


You can add a comment to elaborate on what the Group is or why you’ve added it, but it’s not necessary.

By default, the validity of the group is “valid,” which means that it is active and accessible to those with rights to it. When something is “invalid,” it becomes inaccessible to everyone who is not an administrator.

I’ve created the group as follows:


You should have noticed that I used “Group” in the name. This is because I’m also going to create a Role called “Tier 1,” and having “Group” and “Role” in the names of each one will help me keep them straight.

After you click “Submit,” you’ll be redirected to the Agent-Group relationship management interface. Remember that we don’t want to associate Agents directly with Groups, so you should just cancel out of this step or go back to the overview.

When you return to the list of Groups, you should see yours in the list.[3]


Repeat these steps to create the Tier 2 Group (and a Tier 3 Group if you think you’re going to need one), and then move on to creating Roles.

Create a Role

Creating Roles is just as easy as creating Groups. Go to the Role Management interface by clicking the Roles link in the Admin interface.


Click the “Add Role” button on the left. Just as you did with the Group before, give your Role a name and a descriptive comment. I filled mine out as follows:


Upon clicking “Submit,” you should be redirected to the Role Management interface where you will see your Role in the list.


Follow the same steps to create the Tier 2 Role (and Tier 3 if you need it), then go back to the Admin interface.

Relate a Role to a Group

Now we need to set up the Role-Group relationship. Click on the Roles <-> Groups link to enter the Role-Group management interface:


Remember that you can approach this in one of two ways: you can select a Group and set up access for multiple Roles, or you can select a Role and set up access to multiple Groups. We’re going to pick a Role at a time. You should see your Tier 1 and Tier 2 Roles on the left, with your Groups on the right.


Click the Tier 1 Role to open up the relationship manager for this Role:


We created the Tier 1 Role to grant all Agents with Tier 1 responsibilities access to all the Queues in the Tier 1 Group. To do so, click all the boxes in the Tier 1 Group row.


Click “Submit” to return to the Role-Group relationship management interface. Repeat the same steps to grant the proper rights to the Tier 2 Role, except you’ll want to include rights to both the Tier 1 and Tier 2 Groups.


Unfortunately, we cannot duplicate Role-Group relationships and build on top of them. You have to start each one from scratch. Of  course, that’s still better than having to do it for every single Agent.

We’re giving the Tier 2 Role rights to both groups here so that we can give each Agent a single assignment (Tier 1 or Tier 2) later. An alternative method would be to give the Tier 2 Role rights to only the Tier 2 Group, then to assign Agents with Tier 2 responsibilities to both the Tier 1 and Tier 2 Roles. This is a matter of preference.

Create a Queue

We’re going to venture beyond the Agent Management tools now and use the Queue Settings.


You can see that there are a lot of settings related to Queues. We’re going to do a pretty basic setup that sticks to the system defaults, but you should take some time to explore your options. Queues can have a variety of Auto Responses (messages that the system sends back to Customers automatically based on certain events), Templates (default text Agents can use when replying to Customers), a store of Attachments to associate with different Templates, and Salutations and Signatures that you can sandwich around your Templates. The system comes with a few of these built in, but you’ll have to modify things like the company name and address to reflect your organization.

For now, let’s just build a Queue. We’ll start with the “Unassigned” Queue, as every message that comes in should go there.

Click the Queues link to access the Queue Management interface.


The first thing you’ll see is a list of the built-in Queues.


To add your own, click the “Add queue” button on the left. Creating a Queue is quite a bit more involved than creating a Group or a Role, as you can see from the form.


Luckily, it fills in most of the required fields with system defaults for us. Let’s take a look at each of them.


First, there’s the Name field. If you’re still not sure what to do here, you might not be system administrator material.


Note that I didn’t include “Queue” as part of the name here. This, again, is a matter of preference. Queues are easy to differentiate from other system elements—unlike Groups and Roles, which are virtually identical in form and function.

Sub-Queue of

Next, we have the Sub-queue field. It’s not required, and because “Unassigned” is a top-level Queue in our case, we’re not going to make it the Sub-queue of anything. We’ll revisit this in a bit.


Everyone should have access to the “Unassigned” Queue, so we’ll associate it with the Tier 1 Group.


Unlock timeout

The next setting has to do with ticket accessibility. When a ticket is “locked,” only the Agent who has locked it can take certain actions on the ticket. To prevent situations where a ticket can’t be worked because an Agent is unexpectedly out of the office or has simply neglected too many tickets, you can set an “Unlock timeout” for each Queue.


The system will automatically unlock any tickets that pass the timeout so that any Agent with access to that Queue can take appropriate action on that ticket. By default, this is empty, which establishes no timeout. We’re going to leave it that way in this example.

The next three settings are for escalation. These are also empty by default, which means tickets in this Queue won’t escalate. We’ll leave those blank, but I’ll provide a brief overview of what the settings are, as this is something that we had to review several times before we were all on the same page about how they work:

  • Escalation – first response time
    • The number of minutes from the time the ticket is created until a ticket with the “new” state-type will escalate.
    • You prevent this escalation by taking one of two actions on the ticket:
      • Phone Call Outbound
      • Reply to Customer
      • Note that you must have communication with the Customer recorded on the ticket to prevent escalation
      • Example: If the first response time escalation is set to 10 minutes, you must respond to the customer within 10 minutes of ticket creation to prevent escalation
  • Escalation – update time
    • The number of minutes from the time a ticket acquires an “open” state-type until a ticket with an “open” state-type will escalate.
    • You prevent this escalation by taking one of two actions on the ticket:
      • Phone Call Outbound
      • Reply to Customer
      • Once you make contact with the customer, this timer resets to 0 on that ticket and starts counting again.
      • Example: If the update time escalation is set to 20 minutes, you must communicate with the customer every 20 minutes to prevent escalation.
  • Escalation – solution time
    • The number of minutes from the time the ticket is created until a ticket will escalate if it does not acquire a “closed” state-type.
    • You prevent escalation by closing the ticket.


Notify by

Each escalation type also has a “Notify by” setting.


This tells the system that when a ticket in this Queue is XX% close to the escalation point, send out a notification of that ticket’s escalation progress. Who receives that notification depends on your notification settings.

Follow up Option

Next we have the Follow up Option.


I’ll briefly describe these settings:

  • New ticket – customer replies to closed tickets in this Queue will open a new ticket
  • Possible – customer replies to closed tickets in this Queue will reopen the existing ticket
  • Reject – customer replies to closed tickets in this Queue will be rejected, and the customer will receive an email letting them know their request was rejected.

The default is “possible,” and we’ll leave it there.

Ticket lock after a follow up


The next setting is closely related to the Follow up Option. “Ticket lock after a follow up” determines whether or not the ticket is locked to the ticket’s previous owner when a customer follows up. For example, say I own a ticket that was closed yesterday. Today, the customer realizes that the issue is not completely resolved. (I’m kind of a slacker.) She replies to the closed ticket, either via email or the customer web portal, and that reopens the ticket. If “Ticket lock after a follow up” is set to “Yes,” that ticket will automatically be locked to me. If it is set to “No,” I will still be the Owner, but the ticket will be unlocked.

The default setting is “No.”

System address

If you have configured outgoing mail, you will be able to select which address should appear in the “From” field in emails from this Queue.


You have to choose an address. The system default is otrs@localhost.

Default sign key

If you are using PGP, you can specify a sign key with this setting.

Salutation and Signature


These settings are self-explanatory. If you think of your reply emails as a sandwich, the Salutation and Signature are the bread, and the Template is the marshmallow fluff. (The attachment is the side of bacon.)


Calendars really deserve their own discussion. The basic point is that you can define up to 9 different calendars (plus a system default) in the SysConfig. Each Queue can be associated with any single calendar, but not multiple calendars. If you don’t select one of the 9 named calendars, the Queue will follow the system default.



You’ve seen this everywhere else you’ve created an element with the system. You can turn Queues on and off with this setting.


Add a descriptive comment to the Queue to help explain what it is.


When you hit “Submit,” you will be redirected to the Template-Queue relationship manager interface. Since we haven’t set up any templates yet, you should only see the “empty answer” template. It’s not necessary to associate a Queue with a template immediately (or ever, for that matter). You can come back and manage Queue-Template relationships in much the same way that you manage other relationships.

That’s it. You’ve added a Queue. Follow the same instructions for the “Hardware” and “QA” Queues. You’ve probably already figured out what to do to add the “Printer” Queue, but just to make sure I’m not uncharacteristically concise,  I’m going to explain it in the next section anyway.


It is not possible to add a top-level Queue and a Sub-queue at the same time in OTRS. Even though we knew we needed a top-level Queue for “Hardware” tickets and a Sub-queue specifically for “Printer” hardware, we can only create them one at a time. While we can go back and make one Queue a Sub-queue of an existing Queue at any time, it makes the most sense to have our top-level Queues in place first.

Since you already created your “Hardware” Queue, we’re ready to add the “Printer” Sub-queue. All the steps for adding a Sub-queue are exactly the same as adding a top-level Queue. When making a Sub-queue, we’re just going to select a value in the “Sub-queue of” field.


Once you create a Sub-queue, OTRS uses the notation “Queue::Sub-Queue” to indicate the relationship among Queues.


It is possible to make Sub-queues of Sub-queues, but I am not aware how many levels deep you are allowed to go or if there is a limit.

Once you create a Sub-queue, the top-level Queue is still useable. In other words, you can still use the “Hardware” Queue even after you’ve added Sub-queues. That may seem intuitive, but not all systems work this way.


That about does it for the basics. Between this post and the previous one, you should have a pretty good idea of how to get rolling with OTRS. I’ve got a few more examples of how to get around in the administration interface and do some common tasks in Part 3, so be sure to check that out, too. Again, it’s not that this stuff is that hard to do, but it might save you from spinning your wheels.

Love and kisses,


[1] In this model, QA is a separate Queue. This is a matter of preference. You might prefer to add “QA” as a ticket state, which would not require us to move the ticket and would probably provide more accurate statistics—otherwise, all tickets will be closed from the QA Queue. Creating a separate Queue for QA simplifies the example, so that’s what we’ll do here.

[2] It’s not required that your Roles and Groups match exactly, but it makes the relationships clear and explicit.

[3] Note that alphabetization in OTRS is case-sensitive. “Tier 1 Group” is first in this list because it starts with a capital T.


9 thoughts on “OTRS Config Part II: A Sample Workflow

  1. Every weekend i used to pay a quick visit this site,
    because i want enjoyment, for the reason that this this
    site conations truly nice funny stuff too.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s