OTRS ITSM Part III(b): Your Shop Is a Business


In Part III(a), I mentioned that ITSM (the concept itself, not the OTRS module) really doesn’t make sense unless you think of your shop as a business unto itself. (I said that exactly, in fact. Now I’m just copying and pasting to fill space.) In that post, I focused on thinking of yourself as a business and managing your brand. In this post, I’ll talk about managing your shop’s brand and how ITSM helps you do that.

I’m going to continue with the assumption that you’re in the IT Department of a company, not running your own IT consulting firm. If you’re doing that, you probably know all this already.

A Generic Sketch of A Business

The idea of a business is pretty simple: in exchange for money, a business provides you with goods or services. But there’s a lot that’s implicit there. For example, if you give me a hamburger today, when do you want to be paid?

Probably before you give me the hamburger, right? And did I agree that the hamburger is acceptable if it is medium well and has pickles on it? Or for me to be willing to pay for it, does it need to be medium and have tomatoes and pickles? So let’s refine our definition of a business: In exchange for an agreed upon amount of money, a business provides goods or services that meet an agreed upon standard within an agreed upon amount of time.

In other words, every interaction with a business is a temporary partnership. In the case of buying a hamburger, it’s a pretty short partnership. In the case of purchasing a software license, it can be a long or even indefinite partnership.

IT As Partner

Your IT department provides valuable service to the business it is a part of as long as the work you do aligns with larger business goals. However, in most businesses I’ve been a part of, there’s no direct exchange of money for each service. I hear that large IT departments in big corporations do bill time back to the departments that utilize their services. If that’s not the case for your shop, though, your role as partner might be implicit–or it might be ignored. In fact, you might feel a lot like you’re just a team of go-fers. The business recognizes that it needs IT, but it really just needs a team to do its bidding. It is not offering IT a place at the table so much as keeping them around to pick up the table if it falls over. If you’ve ever been in a meeting where the first time you’ve heard about a new document management system is during the week that you’re being asked to help deploy it (and you didn’t just start working there that week), you’re probably in a shop where the CEO tells IT what he wants without asking IT what’s possible and reasonable.

If that’s all your business wants, ITSM probably can’t help much. It’s unlikely that your “partners” will have respect for the constraints that ITSM will put on your team and your customers. For ITSM to work, other departments must recognize that your expertise can help them be more successful. Password resets and installing new printers is one thing. Deploying new hardware company-wide or integrating new accounting software in the environment are jobs that need teams of experts with proper resources in order to succeed. If you are a partner, the VP of Finance will call you in to review processes and consult on what you can do to alleviate the problem before they tell you what to do. Note that they still get to tell you what to do, and it still might not be what you suggested, but they take your input as part of the decision-making process. In this case, though, you’ve been invited to hold a stake in the project and let your partner know what they can expect you to deliver.

How Does ITSM Help You Be a Better Business Partner?

Back in my first post on ITSM, I gave a brief introduction to some of the categories of IT Service Management. I’m now going to elaborate on how things like Change Management make you a better business partner.

Configuration Management

You’ve probably heard the term “Asset Management.” I used it in Part I of this series. Some will argue that there’s a difference between “Configuration Management” and “Asset Management.” I agree with that, but to avoid a semantic argument, let’s say that Configuration Management includes Asset Management.

Assets are pretty important for a business. If I’m going to sell hamburgers, I’d better have some ground beef. If I’m going to provide electrical services, I’d better have the tools I need that are in working condition. You can see why this would be important for an IT shop. When a new employee starts, you’ll need to know if you have a laptop for them, that it has the latest image installed, that they have an AD username and password, etc.

If someone from HR calls you up and says, “I have a new employee starting on Monday, and I need a laptop for them,” and you say, “Gee… Uh… Okay… Um… I ‘ll have to check and see if we have any laptops…” You’ll have to check and see? That’s not going to be great for your brand. You’ll lose the trust of your partners–and eventually, if none of your partners trust you, they’ll look for ways to go around you. This can only make your life harder.

In addition to keeping track of all the pieces, you also want to keep track of dependencies. It’s not enough to have a motherboard if you don’t have a case to put it in or RAM to accompany it. It’s no use having a server if you don’t have Cat 5 cable on hand. And then there’s the stream of software dependencies when you’re installing something new…

Now imagine that you know exactly how many printers you have, but you don’t know where they are in the building, whether they’re all operating properly, or what their makes and models are. Eventually this will come back to bite your business in the rear. Ideally, you’ll have a database somewhere that contains all of this information. If you can pull up information on what equipment you have and key information about it at any time, that’s going to be great for your brand. Your partners will know that you’re on top of your game and will gain respect for your authority in your domain.

OTRS::ITSM provides a Configuration Management Database.

Incident Management

What do your partners do when they have a problem with your product? How will you record interactions? How will you resolve them and make the resolution repeatable if the event comes up again?

You need some policies and processes in place for dealing with service and purchase requests, complaints, and system alerts. If you don’t have them, you’ll become a firefighter. Every time a customer calls in or raises a red flag, you’ll either have to respond immediately or ignore it, letting it get lost in the shuffle (or maybe exploding not too far down the line). If you want your brand to have the highest possible value, you’ll establish clear policies on how you expect your partners to alert you to their needs and how you expect your team to respond to those alerts.

Of course, if you’re looking into OTRS::ITSM, you know that OTRS already includes pretty much everything you need for incident management in its ticketing system. It’s not the only possible use for the ticketing system, but it’s probably what you’re using it for.

Change Management

We’ve all had one of those “Oh, crud!” moments when we realize we just executed that SQL query on a production server. “Did I make a backup before I did that? Do I know how to restore the backup?” And while it’s bad enough that you’ve made the mistake, you might also be bringing heat down on your boss and any other number of people who interact with that system. This can impact your relationship with your partners as well as your personal brand and team morale.

There are basic things you should be tracking whenever you implement changes in your business, regardless of the scale. The larger the scale of the change, the more important it is to track these things, but it’s always appropriate to track them:

  • What is changing?
  • Why is it changing?
  • Who requested the change?
  • Who is responsible for the change?
  • What will the change impact/what’s the overall scope?
  • When will the change be initiated?

  • When will the change be complete?
  • What is the rollback plan in case of issues/failure?

If you don’t answer all of these questions well before implementing a change, you may be reaching for your disaster recovery kit sooner rather than later. If there’s no agreement about who is responsible for a change, it might never happen. It definitely won’t happen on schedule. If there’s no schedule for initiation, it might end up interfering with other processes when someone just decides to roll it out. And if there’s no rollback plan, there’s no way to mitigate a worst-case scenario.In some cases, a few of those questions will be difficult to answer. “What will the change impact?” for example. Answering this question accurately requires having a detailed understanding of all the dependencies in your business. Your partners may resist waiting on answers to questions like “What’s the overall scope?” They may want to implement the new hiring system by the end of the month without much regard for the consequences. But as you provide transparency into your process and manage lots of successful implementations for your partners, they’ll trust you when you say that something is important and that following your established policies is what allows you to help them reach their goals.OTRS::ITSM to the rescue once again. All this data can be entered into the system and built into a workflow.


IT Service Management is involved. It requires a lot of documentation. It requires imposing constraints on how you do things. If you’re not required to implement it (and even if you are), there will be times when you’ll need a reminder of what is motivating the use of such an elaborate and sometimes cumbersome process. I’ve tried to show how ITSM, and OTRS::ITSM in particular, strengthen your ability to be a reliable, respected, and successful business partner. My motivation here has been the same as for OTRS: if you know how the system is intended to be used, figuring out how to use it is a lot simpler.

I’m not entirely sure where I’ll go next in exploring OTRS::ITSM. If the concepts I’ve explained make sense to you, then the official documentation is really your next step. Let me know if you have specific questions about implementing OTRS::ITSM. Otherwise, I’ll continue to look for gaps in the documentation that need fleshing out.

Love and kisses,



OTRS ITSM Part III(a): You’re a Business


ITSM really doesn’t make sense unless you think of your shop as a business unto itself. This is easy if you’re a consulting or services firm that does contract work. If you’re in the IT department of a company, you might be less inclined to think of your shop as a business or service center, which could mean that you’re in a very reactive shop that seems to shift focus at the whim of whatever VIP last touched base with your boss about what IT should be doing. For all your geeky powers and ability to ruin the entire business with 1 shell script, to a lot of folks outside of IT, you’re just another go-fer. So in the next couple posts I’m going to focus less on your geeky powers and more about having a business-minded approach to yourself and your department.

My Business Cred

I’m not an expert at business, but I’ve had a lot of exposure to running businesses. I’ve been part of a few start-ups; I have several entrepreneurs in my family; and my wife has shared with me pretty much everything she learned while getting her MBA. I’ve also had a lot of success employing the principles I’ll be writing about here, so at the very least I can verify that what I’m telling you has actually worked once.

You’re a Business

This is business 101 for everyone: You, yourself, are a business. Your name is your brand, and your face (or maybe your face tattoo or that weird fedora you always wear) is your logo. Your skill set and the benefits you can provide are definitely drivers of value, but your personality also plays a huge role. Yes, if you’re smart enough, strong enough, fast enough, or unique enough, you can get away with being a huge jerk and still be valuable. Pop culture is full of these figures. Most of the time, though, you can win a job not by being the most qualified candidate but by being the most desirable to work with. A company can teach job skills but generally doesn’t want to work on making you friendly or fun. So you have two major assets as a business: your job-related skills and experience, and your personality.

Managing Your Brand

You need to think about this. What gives your brand value? Are you the printer expert? Are you the ultimate OTRS guru? Are you the jack of all trades who can give the quick answer to any question and knows who to call for more advanced problems? Think about and outline what you offer and how well you’re selling that. If you don’t concentrate on what makes your brand strong, you’ll just be a random IT person. And if you’re a random IT person, you’re a “computer person.” And “computer people” aren’t always highly regarded. The reason is obvious: if you’re the printer expert, but the user’s problem is with their iPhone, to them it doesn’t matter that you can fix printers. You can’t help them with their immediate concern, and so you’re useless. And that’s what they’ll remember–and it will get reinforced every time they have a problem you can’t solve.

This isn’t fair to you, but how are you managing it?

Here are some rules I try to live by:

  • If you have no idea how to fix the problem, be honest.
    • “That’s not my area of expertise, but I’m going to run it by my team and do some research.”
  • Help the user understand the context of their problem and what you can actually do about it. This helps you build expectations correctly.
    • “Well, Sharon, it looks like this isn’t a printer issue. You’re actually not connected to the network at all. I’m going to try a couple basic troubleshooting steps with you, but if they don’t work I’m going to have to call in the big guns. I can help you with all your printer problems, but when it comes to networks, I’m about as much of an expert as Google allows me to be.” (Hey, look at that! Next time Sharon has a network issue, she either knows not to ask you for help, or she knows what level of expertise she’s getting.)
  • Don’t hand off–collaborate.
    • This doesn’t always happen because it can spread resources too thin, but no customer likes to be passed from agent to agent trying to get their problem resolved–explaining the problem over and over again. When possible, stay with the user until either the issue is resolved or your presence is a hindrance. This is a huge value add for your personal brand.


You might be wondering what any of this has to do with ITSM. “Great life advice, Tyler, but I really just need to know how to implement ITSM.” The next post will make clear how this discussion is relevant. Remember that my goal here is not so much to restate the technical details that are already available in the official documentation but to provide context for the implementation and the mentality that will help you design a successful setup.

Love and kisses,


OTRS ITSM Part II: Installation


There are only a couple of paragraphs on OTRS::ITSM installation, but it turns out that there are a couple of gotchas in that small a space. I’ll cover those here.

Scope of Application

  • Amazon EC2
  • RHEL 6.6
  • OTRS 4 (patch level 9)
  • OTRS::ITSM 4 (patch level 9)

Install OTRS

It may not be obvious, especially if you are new to OTRS, but OTRS::ITSM is not a stand-alone piece of software. It is a package (actually a set of packages) that you add to an existing instance of OTRS. So before you can install ITSM, you’ll need to have OTRS up and running. You can find information about how to install OTRS in the official manual. Then you can check out my posts on getting started with OTRS for your initial configuration. If you’ve already done all that, you’re ready to install ITSM.

It’s Not as Easy as It Looks (But It’s Still Easy)

The official documentation offers a couple options for downloading the necessary packages: either enter some specific text into the package manager (Admin->System Administrator->Package Manager), or download the packages manually from the FTP site. I didn’t have anywhere to enter the provided text on the Package Manager page and had to go with the option of downloading from the FTP site. Unfortunately, even though the manual is for ITSM 4, the link provided will take you to the packages for ITSM 3.3. To get the correct packages for ITSM 4, you need to visit ftp://ftp.otrs.org/pub/otrs/itsm/packages4/, which should look something like this:


From here, right-click the package you want (I just grabbed the latest version of each package), select “Save Link As…” (they’re XML files), and save it to somewhere you know you can find it in a minute. As the manual says, you need to install GeneralCatalog and ITSMCore first.

Note: When selecting packages, make sure you get the same version number for each package. In other words, if you get GeneralCatalog-4.0.9.opm, make sure you also get ITSMCore-4.0.9.opm.

Once you have the packages you need, just select them with the Browse button under “Actions” on the Package Manager page (top left), click the Install Package button, and follow any prompts or instructions. These prompts will usually let you know if there are prerequisites or if you’re trying to install an incompatible version.


Repeat these steps for the remaining packages on the FTP page. See? Easy.

Love and kisses,


OTRS ITSM Part I: What is ITSM?

[A couple of boring paragraphs about why I’m writing these posts. Skip to next set of brackets to ignore. :]

What seems like a long time ago now, I wrote a few posts on how to configure the online ticketing system OTRS. While it’s a great system with thorough documentation on how to install the system and configure it, I felt that there were some gaps in the official documentation. So I made some up and wrote a brief manual on the basics of getting started with OTRS, split up over three posts. To my surprise, those posts have brought a consistent stream of traffic to this blog ever since. I’ve received quite a few kind and encouraging comments, which I really appreciate.

In addition to those comments, I get questions. The question I get most consistently is this: Will you do a similar series on ITSM? I promised I would, but in the meantime I had changed jobs and was no longer working with OTRS on a daily basis. On top of that, I started going to school part time. So while I’ve had it on my to-do list to write these posts for well over a year, it took until now for me to work in the time to write them. But it’s finally happening. For those who have been waiting for these posts, thanks for coming back. Sorry for making you wait so long…

[Okay, on to the meat of the subject.]


This post will cover the basics of what ITSM is and why you would want to use it. It’s not meant to be a replacement for the official ITSM manual (which is really well done, btw), but since you were nice enough to stop by and see me here, I’m going to give you my take.

Scope of Application

I won’t be going into a lot of technical detail here, but just so you know where the starting point will be on the technical side, I’m now running OTRS 4, patch level 9 on an Amazon EC2 instance. The OS is RHEL 6.6, which means all the following should apply to CentOS, as well. I’ll be working with OTRS::ITSM 4, patch level 9.

IT Service Management

That should clear up what ITSM stands for. (If you don’t know what IT stands for, you’ve come to the wrong blog–the wrog, maybe.) But what is it?

The official documentation gives a brief reminder of ITIL and the standards that exist for IT best practices. If you’re in a shop that is or wants to be ITIL certified, you’ll be well versed in this. If you’re not part of one of those shops, you still probably want to employ industry best practices whenever possible. A big part of the appeal of OTRS is that it is (or at least claims to be) fully ITIL compliant–meaning it will help you enforce best practices. Being open-source and fully customizable means that you’re not bound by those practices and can implement your own strategies, but you’ll start with an ITIL compliant foundation.

“But Tyler,” you say, “I don’t know what ITIL is, and I’m pretty sure I don’t care. I just want to know that IT Service Management is.” Okay. Fine. From here on, I’m going to assume that if you’re looking into OTRS::ITSM, you’re already familiar with the OTRS ticketing system. If not, check out my series on that.

Incident Management

If you work in IT, there aren’t a lot of standard days at the office. That’s what attracts a lot of people to the work–the only constant is problem-solving. There’s always a problem. In the last few weeks, you’ve probably had to reinstall someone’s printer driver, reset a password or two, flushed some caches, imaged a couple machines, etc., etc.

If somebody asked you to write a job description for your position, it would either be incredibly long, or it would just say this:

  • Ideal candidate will know everything about computers and all peripheral technologies and be ready to fix every possible problem at a moment’s notice, likely under duress.

This is why you have a ticketing system like OTRS. Requests are constantly streaming in, and you need some way to organize and prioritize them. This is incident management, and it’s one part of ITSM. But wait… there’s more!

Asset Management

You may have a storage room somewhere that looks like this:

If you were lucky enough to be in that shop before anybody started thinking about asset management, you may have even been lucky enough tog et to catalog everything that was in that storage room as you asked yourself, “Why in the world are we hanging onto this?” Well, part of ITSM is establishing (and hopefully following) the policies and practices for things like tracking equipment, deciding when and how to buy new equipment and who’s responsible for approving it, etc. It’s not usually fun to walk into someone’s office to help them with their printer problem and find out that they bought their own printer and want you to make it functional on the office network.

Change Management

This is a big one, and it’s too often neglected. When you are making changes in production, no matter how sure you are that everything will be fine, there’s a good chance that some edge case you weren’t ready for will interfere with your plan. Change management is planning what the change will be, when the change will happen, who is responsible for the change, and, probably most important, the roll-back strategy in the event that the change fails or breaks something. OTRS::ITSM provides tools for handling this whole process.


I’ve covered some of the high-level categories for IT Service Management as an overview of what OTRS::ITSM aims to help with. But to get even more general, ITSM covers any of the policies and practices that help IT deliver the services needed to help the business reach its goals. That’s a pretty broad task, which means that OTRS::ITSM has a lot of features. My goal isn’t to cover them all. I’m going to do with these posts what I did with the original OTRS series and make recommendations for the initial setup while also trying to elaborate on any “gotchas” in the system. Hopefully it will be useful to those who find the official documentation overwhelming.
Love and kisses,Tyler

OTRS Config Part III: The Admin Interface and Common Tasks


This will be the last of my planned posts on OTRS configuration. If you missed Part 1 or Part 2, be sure to check them out.  This post covers more concrete tasks and is less concerned with the abstract ideas covered in the first two posts. The content here was prompted by particular business needs, but based on my experience so far, it should have a pretty wide scope of application. Speaking of which…

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.

Admin Interface

The majority of the system configuration you do will be through the Admin tools in the OTRS web interface. This includes tasks we’ve already reviewed, like creating Groups, Roles, and Queues; assigning permissions; and associating different elements. OTRS has a relatively sophisticated set of administrative tools. The relationships of the various modules will take time and practice to master, but they are ultimately quite simple to navigate.

The one possible exception is the SysConfig interface, which we will look at next. Once you understand how it organizes the configuration modules, you will be able to take advantage of its power and convenience.


Much of the configuration of OTRS can be done through the SysConfig interface. Access the SysConfig interface by logging into OTRS and clicking the Admin tab. (If you do not have Admin access in OTRS, you will not see this tab.) SysConfig is in the System Administration group.


When you first open the SysConfig, there’s not much to see. The default view shows no modules. You begin navigating using the Actions sidebar on the left.


You can type specific terms into the search field, or you can filter by config groups. These groups take a little getting used to. As you get more familiar with the naming conventions used by OTRS, navigating to specific modules and properties via the config groups will get easier. The nice thing about OTRS being so popular is that you can find a lot of help online. (Note the self-fulfilling prophecy I just made!)

Before we get to looking at any of the modules, let’s Export the current settings.[1]

Exporting and Importing Settings

It is important to get into the habit of exporting the configuration settings before you make any changes—and especially before importing another collection of configuration settings.

Click the “Export Settings” button. You should see a dialog prompting you to save a Perl module file


Save the file somewhere that you can access it easily.

To import settings, click the “Import settings” button, browse for the file, and click “Submit.”

Module Access

Turn off Agents < – > Groups Assignments

Out of the box, OTRS allows you to assign Group rights directly to individual Agents.[2]


We’ve already reviewed the reasons that motivate us to assign Agent rights through roles exclusively. To enforce compliance with this policy, we can turn off access to the module that allows us to associate Agents directly with Groups.[3]

Note that turning off access to the module is not the same as disabling it. Any Agent-to-Group associations that have already been made will still be in place. Also, any action that redirects to the Agent-to-Group assignment will still be able to reach the module. The primary advantage of turning it off is that it eliminates accidental clicks and the amount of options you have to process as you perform administrative tasks.

Follow these steps to turn off the link:

  1. Navigate to the SysConfig interface.
  2. Select “Framework” from the dropdown on the left.


  3. Locate the module Frontend::Admin::ModuleRegistration and open it.


  4. Locate the property Frontend::Module###AdminUserGroup.


  5. Uncheck the box next to this property.


  6. Scroll to the bottom of the page and click Update.
  7. To make sure you’ve turned off the link, go back to the Admin interface. You should no longer see “Agents < – > Groups” under the Agent Management settings.



It is possible to change the workflow routes of OTRS, helping to prompt users through the experience they prefer.

Set the page Customers see at login

By default, when customers log on they see an overview of their open tickets. If that’s what your customers are used to, that’s great. But many customers are used to seeing a ticket entry screen when they log on to their help desk. To ease the transition to OTRS for these folks, we would want to preserve that experience.

  1. Navigate to the SysConfig interface
  2. Select “Ticket” from the dropdown on the left
  3. Locate and select Frontend::Customer
  4. Locate CustomerFrontend::CommonParam###Action. By default, this is set to CustomerTicketOverviewcustomerfrontend-action-overview
  5. Change the value to CustomerTicketMessagecustomerfrontend-action-message
  6. Click “Update”
  7. Log into the Customer portal to confirm that you are redirected to the new ticket view by default

Tip: You can often find out the name/value of a particular view by visiting that page and examining the URL


Changing the Appearance of OTRS

Change the Headline and Logo

default-headline                                                                          default-logo

OTRS uses its own logos and icons by default. Wouldn’t you? To place your own brand on the environment, you need to change the headline and logo. First, you’ll need an image. The OTRS blog recommends that the image be 135 x 50 pixels, but you can figure out the best size for your image through experimentation. In our case, let’s assume the image is named HelpBrand.jpg.

  1. Place the image in $OTRS:var/httpd/htdocs/skins/[Agent | Customer][4]/default/img
  2. Navigate to the SysConfig interface in OTRS
  3. Select “Framework” from the dropdown on the left
  4. Locate and select Frontend::Customer
  5. Change CustomerHeadline from “Example Company Support” to your desired text
  6. Find the group of CustomerLogo settings and change the URL to skins/Customer/default/img/HelpBrand.jpg
  7. Click “Update”
  8. Navigate to the Customer portal. You should see your changes reflected there

This help desk is gonna fly now!


To change the logo on the Agent side, adjust the corresponding AgentLogo settings in Frontend::Agent.

Ticket Settings

This section covers different ways to change what users and agents can and must input when filling out a ticket.

Make Time Units Mandatory

Agent tickets have time accounting turned on by default, but it is not a required field. Many organizations want time accounting to be required. Here’s how to do that:

  1. Navigate to the SysConfig interface
  2. Search for “time units”
  3. Depending on what packages you have installed, you may see only see one result here: Frontend::Agent. If you have the iPhone module installed, you will see more results. Select the subgroup “Frontend::Agent” in the group “Ticket.”
  4. There are a couple dozen settings here. You can use Ctrl + F to search for “time” or “account.”
  5. Ticket::Frontend::AccountTime should be set to “Yes”ticket-frontend-accounttime
  6. We are specifically looking for “NeedAccountedTime.” OTRS uses “Need” as a keyword to indicate that a field is required.[5] By default, this is set to “No.” Change it to “Yes.”ticket-frontend-accounttime-drpdwn
  7. Click “Update”
  8. Create a new ticket as an Agent by clicking Tickets>New Email Ticket
  9. Scroll down until you see the “Time units” field. It should have a star by it and be in black text instead of gray.


Add a New Ticket button to the customer interface

Out of the box, OTRS includes the “New Ticket” button in a dropdown menu in the Customer’s Ticket Overview interface.


While this may be accessible enough and intuitive to the vast majority of users, the dummies like me need a button that they can access a little more directly. Otherwise, we spend the first couple of weeks filling out phone request tickets for how to access the New Ticket button.

  1. Navigate to the SysConfig interface
  2. Choose “Ticket” from the dropdown on the left
  3. Find and select Frontend::Customer::ModuleRegistration
  4. The first group of settings is CustomerFrontEnd::Module###CustomerTicketOverview. This defines what the customer will see in the various menus and submenus throughout the customer interface. We’re going to stay within the CustomerTicketOverview section, but I recommend that you look over all of these settings and get familiar with them.sysconfig-customerticketoverview
  5. Notice the NavBarName property. By naming the NavBar, we are able to group and order actions, as well as persist a single NavBar across views.
  6. Scroll to the bottom of the NavBar entries, for CustomerTicketOverview. If you’ve made no changes, there are two of them: “Tickets” and “My Tickets.”
  7. Find the plus sign after the last entry, and click it.sysconfig-customerticketoverview-detail-filled
  8. The page will reload and give you an empty set of parameters. Fill them in as follows:
    • Description:       New Ticket
    • Name:                   New Ticket
    • Link:                      Action=CustomerTicketMessage
    • Priority:                90
    • AccessKey            n
  9. Click “Update”
  10. Log into the Customer portal. You should now see the “New Ticket” button in the NavBar


Dynamic Fields

Dynamic fields are how you gather information the developers of OTRS either didn’t think about or didn’t care about when they designed the system. Every organization has their own interests, and OTRS provides the flexibility to customize what data you’re tracking and presenting. We’ll look at one example: adding a branch name to a ticket. Warning: This is a long one! Adding dynamic fields and confirming they work takes quite a bit of setup.

Add a Branch field to the ticket

  1. Navigate to the Dynamic Fields Management interfaceticket-settings-tools
  2. Select “Dropdown” from the Ticket dropdown on the left.dynamicfieldsmanagement-overviewticket-dropdown
  3. Fill out form with the following details:
    • Name:             ddBranch
    • Label:             Branch
    • Field order:    1 (don’t worry about replacing anything that’s there)
    • Validity:         Valid
  4. Click the plus sign next to Add valueadd-value
  5. Set the Key to “101” and the Value to “Support Group”
  6. Set the Default Value to “Support Group”drpdwn-settings-supportgroup
  7. Leave the remaining settings as they are, and click “Save”
  8. Your new Dynamic Field should appear in the Dynamic Fields Listdynamic-fiels-list
  9. Navigate to the SysConfig interface
  10. Choose “Ticket” from the dropdown on the left
  11. Find and Select Frontend::Customer::Ticket::ViewNew
  12. Find Ticket::Frontend::CustomerTicketMessage###DynamicFieldticket-frontend-dynamicfield
  13. Click the plus sign
  14. Enter the key of your Dynamic Field (in this case “ddBranch”) and set the Content value to 1 (Enabled)key-content-filled
  15. Click “Update”
  16. Go back to the SysConfig interface
  17. Choose “Ticket” from the dropdown on the left
  18. Find and Select Frontend::Agent::Ticket::ViewZoom
  19. Scroll down to Ticket::Frontend::AgentTicketZoom###DynamicField
  20. Click the plus sign.
  21. Enter the key of your Dynamic Field (in this case “ddBranch”) and set the Content value to 1 (Enabled)
  22. Click “Update”
  23. We’re almost finished, but we need to make sure that OTRS displays the entire value of the field without truncating it. So go back to the SysConfig interface one more time
  24. Choose “Ticket” from the dropdown on the left
  25. Locate and select Frontend::Agent
  26. Locate Ticket::Frontend::DynamicFieldsZoomMaxSizeSidebar
  27. The default value is 18 characters. Set it to 140 (or whatever length you know you need)fields-zoom-max-sidebar
  28. Click “Update”
  29. Log into the customer interface
  30. You should see your  new field at the end of the default fields with your default value selectedbranch-dropdown
  31. Fill out and submit a test ticket
  32. Log into the Agent interface
  33. Locate and open your test ticket
  34. You should now see your Dynamic Field in the Ticket Information sidebar



I’ll continue to use OTRS and so may come across something new to share from time to time, but this ends my original trilogy of configuration posts. OTRS has plenty more features to explore, but we’ve covered all the major bases.  If you followed me this far, you should be able to tackle quite a bit more on your own. Feel free to use the comments here to drop a line and ask me questions. If there’s any way I can lend a hand, I will.

Love and kisses,


[1] Technically, OTRS actually stores all of its default settings. Anything you change in the SysConfig can be reset to the defaults pretty easily. Backing up the settings will become increasingly important as you customize the environment further.

[2] If you are not sure what Group rights are, review the OTRS documentation on Groups.

[3] Of course, the System Administrator will always be able to turn access to this module back on, but removing the option from plain sight will help us avoid mistakes.

[4] [Agent | Customer] should be read as “Agent or Customer,” and indicates that you will need to put it in each of the directories. The tree structure is otherwise the same. In the example, we’ll be changing the image on the Customer side.

[5] OTRS also sometimes uses the word “Mandatory” instead of “Needed.” See Ticket::Frontend::CustomerTicketMessage###ServiceMandatory.

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.

OTRS Config Part I: Understanding Queues, Groups, and Roles


This is a reference for folks configuring (or thinking about configuring) an OTRS Help Desk in-house. OTRS Help Desk is an open-source trouble ticket system. It’s one of the most sophisticated and widely-used technical support systems out there. I’ve helped implement a few help desk systems over the last year, and I’ve been especially impressed with OTRS, especially considering that it’s free!
The documentation and community support for OTRS are equally impressive, but I found a few bits and pieces  a little difficult to wrap my head around at first. The official documentation was a good start, and there were some forum discussions that helped. But, I’m a dummy. And as I am wont to do, I started making notes to explain it to myself. I’m in the habit of doing this for two reasons.
First, projects stall out. You work hard on something for a month, you’re just getting into a groove and reaching maximum productivity when you have to stop work on project A and move to project B. Two weeks later, project A is top priority again. You’ve forgotten most of what was at the front of your mind, and now you have to start the learning process all over again. When I make my own notes, that re-ramp goes a lot quicker.
The second reason I make myself notes is turnover. You never know when you’re going to be out sick, find another job, or have to hand a project off to someone else for any number of reasons. There are things about any implementation that are unique to your organization, and having that stuff documented, at least in some form, makes for much smoother transitions.
I’m not officially a trainer, but documentation also helps with training. You don’t have to rely on your own memory for everything, and you can give people homework! (Maybe that’s how you ended up here right now!)
Anyway, I thought these notes might be of use to others trying to set up OTRS for the first time. This will be the first part of a series of posts on configuring OTRS. It will cover some of the high-level concepts about how to organize access rights within OTRS. If you’re planning to implement OTRS, this can help you plan an effective setup and possibly save you some refactoring of your environment later.

Scope of Application

(The “scope of application” section is a convention I’ll be using regularly. Software gets updated, blog posts go out of date, etc. It can be really useful to know what the original author was working with to figure out if any of it applies to you–and how directly.)

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 set up your own installation (they have it for Windows and Mac, too) to follow along. But I’ll provide plenty of screenshots.


This is the first of three posts. If you like what you read here, you might want to check out Part 2 and Part 3.

Queues, Groups, and Roles

If you’re going to use OTRS, you will benefit from a detailed understanding of Queues, Groups, and Roles—and the relationships between them. Read the OTRS documentation on these subjects, and accept that mastery of these concepts will require some practice. I provide a brief description of each item here, and I follow that with a concrete example.

(Settle in for it. This is a long one!)

(Also, just so you know, I’m going to be weird about capitalizing the terms Queue, Group, and Role. It just helps me keep everything straight.)


When a customer reports an issue or incident, whether through the web interface or by sending an email directly into the system, this is a “Ticket.” We can organize or collect tickets into user-defined Queues. It might be helpful to think of Queues as issue categories or problem types.

In a shop of any size, it’s not hard to imagine a period of a few hours where tickets come in for a variety of issues: hardware, software, network, phone, etc. By collecting tickets into common buckets that reflect the type of problem at hand, we can target our focus and our efforts. It can also help managers make faster and more accurate decisions about how to prioritize the current workload.

You define what Queues and Sub-queues you want to use. OTRS provides a few out of the box, but they are non-descript. By default, tickets flow into a single Queue, and you can reassign them from there based on the content of the ticket. As you gain a better understanding of the system features, you can start filtering tickets to specific Queues or use multiple incoming email addresses (or aliases) to direct tickets to the desired Queue.

When you create a Queue, you will need to associate it with a Group. Group rights are how you define Queue access. Before you create your Queues, you’ll need to create some Groups.

Tip: It would probably be a good idea to define your Queues and Groups on paper first. In my mind, you would want to define Queues first, and then you can define the Groups that should have access to those Queues. Once these are defined, in OTRS you would create the Groups first, and then the Queues. You can experiment with creating the Groups and Roles within OTRS as you define them, but keep in mind that you cannot delete them from the system. You will avoid clutter by defining Queues, Groups, and Roles before you start creating them in the system.


Groups in OTRS should be thought of as collections of access rights. To some extent, you can also think of Groups as collections of Queues, though that limits their scope a bit. There are a few modules, including Stats (reporting) and FAQs, that don’t have Queues associated with them by default, but you still define access rights to their functionality through Groups. For this reason, you should not get in the habit of thinking of Groups exclusively as collections of Queues.

Groups define the following rights:

  • MOVE_INTO (move tickets into these queues)
  • CREATE (create tickets/articles in these queues)
  • NOTE (add notes to tickets in these queues)
  • OWNER (change the owner of tickets in these queues)
  • PRIORITY (change the priority of tickets in these queues)
  • RW (read-write access to tickets/modules in this group)
  • RO (read-only access to tickets/modules in this group)

You can see that the first five rights apply primarily to Queues, while the last two (RW/RO) are more closely related to modules like Stats and FAQ. Nevertheless, there is some overlap. Develop a bias toward thinking of Groups as collections of rights rather than collections of Queues.

When you associate a Queue with a Group, you are granting all the access rights defined by that Group to the selected Queue. (Don’t worry, there will be pictures soon.)


Now that you have some Queues that allow you to classify tickets, and you have Groups that define access rights to those Queues, you need to find a way to grant those rights to an Agent. There are two ways to do this. The first is to assign Agents directly to Groups. This is not generally regarded as best practice for large implementations. Instead, I recommend setting up Roles. Using Roles instead of assigning Group rights directly to Agents offers the following advantages:

  • You only have to configure the rights once, for the role.
  • You can associate multiple Agents with a Role in one swoop.
  • When Agents assume or discard a Role, you can add/remove rights by disassociating them from the Role—no need to update multiple rights on multiple groups.
  • When the responsibilities of a Role change, you only have to update them once for everyone associated with that Role.

The trade-off of using Roles is it requires a little more work up front. You have to define your Groups and Roles clearly to make sure that Agents get the rights they need. In the long-run, though, it will simplify administration.

Concrete Example of Queues, Groups, and Roles

Our Company and Where We’re Starting From

You work for the IT Department of Anonymous Business Company (ABC), a company of about 1500 employees with branches spread throughout the United States. You have a central IT location, so the vast majority of your support is handled remotely.

You have been using a home-brew Help Desk system for several years. Now that the company has grown, you’ve decided to implement OTRS to add functionality and features to your Help Desk that won’t require an investment in custom software development. You know that OTRS is powerful software that will bring you a lot of advantages, but it’s up to you to get the configuration right so this will be a smooth transition.

You’ve read through the OTRS documentation and understand that creating the right Queues, Groups, and Roles are vital to setting up an efficient workflow. Luckily, you’ve been in business for quite some time already. You’ve got a pretty effective workflow. There’s room for improvement, but you don’t have to start from scratch.

What OTRS calls Queues, you’ve called Categories—or work categories. OTRS is going to upgrade how you work with those categories, but the basic concept is the same. What they call Roles, you’ve also called Roles—Tier 1, Tier 2, Tier 3, Manager. What they call Groups, though, is new to you. You’re not quite sure where those fit. You know Groups define system access rights, but your home-brew system only had one set of rights. If you were in the system, you could do anything. Access and rights were enforced through training team members on what tickets they were responsible for and which ones they shouldn’t touch.

Let’s look at our current workflow. Before we start trying to upgrade or make changes, we’ll just try to match what we’ve got now as closely as possible.

Existing Workflow (Simplified)


Note: Oversimplification

The above example is, admittedly, oversimplified. To design your Queues, Groups, and Roles, you’ll need to have an intimate understanding of your entire process. For example, which Roles are allowed to review requests? When they assign it to a category, how do they determine which category it should be? When they assign it to an individual, how do they determine which individual should work the ticket? What does it mean to “work a ticket” or to “QA the work”?

I don’t attempt to answer those questions. Instead, I offer a more abstract example that doesn’t distract from primary concepts by going too deep into details that may or may not match your workflow. The above pattern should match that of any IT department that has committed to or is working toward industry best practices.

Matching the Existing Workflow

Based on the workflow above, we know we’re going to need OTRS equivalents for the following:

  • A web interface for entering requests
  • A way to label tickets as “Unassigned”
  • An account with permission to view and assign tickets
  • An account with permission to work a ticket
  • Multiple ticket categories and a way to label a ticket with its category
  • A way to label tickets as “In-Progress”
  • A way to label tickets as “QA”
  • An account with permission to view, update, and either reassign or close tickets labeled as QA

First, let’s just see if there’s a direct translation in OTRS for each of these:

Current System OTRS
Web Interface Web Interface
Way to label tickets “Unassigned” User-defined Queues
Account w/permission to view and assign Group/Role combinations to define and grant rights
Account w/permission to work a ticket Ditto
Multiple ticket categories and a way to label a ticket with its category User-defined Queues
A way to label tickets as “In-Progress” Combination of user- and system-defined ticket states
A way to label tickets as “QA” Multiple solutions. No one-to-one match
Account with permission to view, update, close QA tickets Group/Role combinations to define and grant rights

Not everything has a one-to-one match, but we’re pretty close. So let’s go ahead and try to create this workflow in OTRS.

Defining Queue-Group-Role Relationships

Before we create any Queues, we should really have some Groups and Roles in place. Earlier we identified Tier 1, Tier 2, Tier 3, and Manager as Roles in our current environment. They represent different scopes and levels of responsibility. But tickets go into Queues, and Roles can’t access Queues directly. They have to access them through associations with Groups… Ugh!

Before we try to tackle that, let’s see what the Queue-to-Role relationships are.

Consider the following relationship diagram, where the boxes are the Queues, and the figures with the checkmarks by their heads are the Roles:


This may or may not match your organization’s relationships exactly, but you can see that those with a Manager Role have responsibility for 6 Queues where those with a Tier 1 Role only have responsibility for (and therefore access to) only 3 Queues. You probably have a similar hierarchical model, whether formal or informal.

  • Standard requests can be fielded by any member of the team.
  • Network outages will be assigned to Tier 2 and above because these folks have enough training and familiarity with the environment to respond with the appropriate urgency.
  • Only Tier 3 and above can respond to VIP requests, as VIPs require distinct treatment.
  • Finally, only Managers have permission to approve and execute large hardware expenses.

Think about how your department handles different categories of problems with varying degrees of severity. You can probably come up with a diagram a lot like the one above to similarly define the Roles and Queues you’ll use in your organization.

The scope of responsibilities for each Role ends up looking something like this, growing with each additional Role:


Okay. We have an idea of a few Queues we want to use, and we have some idea of what Roles we’ll need and what kind of access they should be granted. How do Groups fit in?

To get a better sense of how using Roles can make your life easier, let’s take a look at the Agent Management tools in OTRS.


For a moment, let’s assume you don’t trust me. (And why should you?) You don’t buy this whole notion of using Roles to intermediate between Agents and Groups. OTRS provides a way to assign Agents directly to Groups, so let’s just do that.


When you manage Agent-Group relationships, you can either select a single Agent and make multiple Group assignments or select a single Group and make multiple Agent assignments.


Let’s start by selecting a Group.


Notice that this is actually pretty accessible. If you want to give all users MOVE_INTO rights to Queues in this Group, you just click the top checkbox in that column, and everyone gets those rights.


There are a couple limitations, though. You can only set rights for one agent or one group at a time. There’s no way, for example, to give Manny Manager and Tami Threetier Tier 1, Tier 2, and Tier 3 rights at the same time. You’d have to either give Manny rights to the three groups, then give Tami rights to the same three groups, or you’d have to give them both rights to Tier 1, then to Tier 2, then to Tier 3. Now imagine that you have half a dozen Groups and fifty Agents.

Actually, let’s look at an example with a larger user group. Here would be the Tier 1 Group access settings in a system with 16 Agents (including root):


Simple. Everyone who is an Agent is at least a Tier 1. Just click that top check box on each column (7 clicks). But say that only five of my folks are Tier 3. To set my Tier 3 rights to the below costs 35 clicks:


And now imagine that you want Tier 2 people to have MOVE_INTO rights to Queues in the Tier 3 Group. You don’t want them working those tickets, but you want to give them a chance to direct them to the right place. Clickety-click-click.

Three weeks later, tmoore is relieved of Tier 3 duties. The poor fella just wasn’t ready. That’s 7 more clicks to take those rights away. Two months after that, four Tier 2 folks get promoted to Tier 3—28 more clicks. The relationship looks a little like this:


We have to manage 16 individual relationships with the Tier 1 Group. That’s a lot of maintenance.

With Roles we simplify administration and cut down on potential and actual errors by reducing the number of clicks. The initial setup will seem just as labor-intensive, but if you design the relationships well, it will make long-term maintenance exponentially easier.

Let’s look at Queue-to-Role relationship with the Groups intervening (Manager Role and Group omitted for the sake of space):


Instead of having to manage 16 relationships with the Tier 1 Group, we only have to manage 4 (including the Manager Role—not pictured).

I know what you’re thinking. There are still 16 relationships to manage. How is throwing Roles into the mix making that easier? Don’t we have to manage 20 relationships now? Well, technically yes. But before you throw out the baby with the bathwater, let’s look at the Admin interface in OTRS again.

Managing Role-Group relationships is exactly the same as managing Agent-Group relationships. You can manage the relationship between a single Role and multiple Groups or between a single Group and multiple Roles.


In our case, it makes more sense to manage a single Role with multiple Groups. For the sake of this example, we have Groups and Roles for Tier 1, Tier 2, Tier 3, and Manager. Look at the settings below in order:

Tier 1 Role:


Tier 2 Role:


Tier 3 Role:


Manager Role:


These assignments should remind you of something…


It’s clear that administering these four relationships instead of 16 will be easier. We’ve cut out 75% of the effort. Well, almost. We still have to manage Agent-Role relationships.

The first thing you’ll notice is that the Agent-Role relationship management interface looks exactly like the other relationship management interfaces:


So what’s the difference? Let’s look at our Tier 3 assignments:


Instead of setting 7 rights per Group for each Agent, we only have to click once per Agent to assign them all the appropriate rights for the Role. By setting up the Role permissions correctly once, we’ve eliminated the need to set them up again for each Agent. And remember how we set up the Tier 3 Role so it includes all the rights to the Tier 2 and Tier 1 Groups? When we manage the Tier 2 Role relationships, if we forget to put a check next to tmoore’s name, he’ll still have all the rights he needs (until a couple weeks from now when he gets demoted again).

Remember the situation we considered before where we determined that folks in the Tier 2 Role should have MOVE_INTO rights on Tier 3 tickets so they can redirect tickets to the proper Queues. Suppose we have 10 Tier 2 people at that time. To change the rights for all 10 people, we only have to click once in the Tier 2 Role.


Easy peasy. Right?


There is a trade-off. It’s a minor one, in my opinion, but it’s worth noting. When you make direct Agent-to-Group assignments, you can refine the rights to a much higher degree. This may offer certain advantages in smaller shops where there aren’t really defined Roles (and you have the administrative slack to edit the access granted to individuals completely willy-nilly). Hopefully it’s clear that in larger organizations, you’d just be asking for trouble trying to administer every individual’s rights to every Group—especially where positions are fluid or turnover is high.

If Groups, Roles, and Queues still seem completely mysterious, I have some exercises designed to walk you through setting up a system to accommodate a sample workflow in Part 2. There’s also a Part 3, if you want to skip Part 2.

Love and kisses,