Mail (Request) Forwarding à la Post Office

Shawn Beasley28. Jun 2019 | AdministrationUse cases

Sometimes spring cleaning just isn’t enough. You’ve changed the wallpaper and painted the fence, but it’s just not doing it. It’s time to move, which is a happy-sad event and not always easy.

Like moving homes, moving from one version of software to another may lead to questions like:

• Should we make a clean cut from the old OTRS installation and start a new?
• Is it time to create new queue and services?
• Do we need new users, groups, roles, etc.?

What about the old tickets? How will we deal with them?

Before you let the task of leaving the old behind and moving to new horizons overwhelm you, read further…….

The biggest issue you face after deciding to start a fresh with OTRS is: How do we handle requests which are still open? How do we redirect our mail without loosing contact with the requests which were part of the old system and still need answering?

You surely do not want to work out of two different systems. Also, changing email addresses after all those years of having your customers write to you at the current address may not be desirable.

So, how do you have your cake and eat it too?

The postal service of most countries offers mail forwarding. This means that after a move, your current address will forward mail to your new address. Similarly, with OTRS, we will arrange for something similar. Your new instance of OTRS should allow the customer to use old ticket numbers while continuing to provide agents access to the previous conversation thread.

OTRS makes this happen by this using the feature External Ticket Number Recognition.

To use this, one thing we need to understand is the ticket number structure. Each OTRS is individual. You can:

• define the type of ticket number to be used (NumberGenerator),
• make it unique (SystemID),
• define the identifier for the ticket number (Hook),
• and make it a bit more readable (HookDivider – not depicted below).

These properties allow OTRS to identify if this is a ticket number or just some random collection of identifiers in the subject (or body) of a message.

Ticket Number Disection

If the Hook, HookDivider, or Number do not match, then it’s not a valid ticket number. If all of these things match, then the SystemID comes into play. This is the number we will latch on to in a moment. A post office forwards its mail to the new address based on the registered last address: Our registered last address is the old SystemID.

This is where the example of the post office starts to crumble in relation to what we are trying to achieve, so let’s leave this analogy for now.

When your new system is up and running, it’s crucial that a new SystemID be chosen. Now, all of your new emails are being polled by the new system. Since the new SystemID is not found in the ticket number (as the number itself is not registered) new tickets end up being created for old requests, and you also end up having no idea what the old tickets have for content. In comes External Ticket Number Recognition and Dynamic Fields.

By configuring External Ticket Number Recognition, you can process all new emails to look for the old pattern. The key here is the SystemID, as this is the same in all tickets. When this pattern is found, OTRS saves the ticket number in a dynamic field (done automatically by OTRS for tickets not already containing an external ticket number). The dynamic field is configured to link to your old (archive) system, so that the conversation is not lost. Agents can read things from the past in the old system, but they will answer from your new system.

At this point, the new ticket number is connected via the dynamic field to the old ticket number. Your customer users can then respond to the new request using the old ticket number or the new ticket number. Eventually, all the old requests will be closed in the new system.

The only requirement you have is to keep the old system alive so that your agents can quickly reference any past conversations via the hyperlinked dynamic field.  In the example below you will see that the number is parsed from the incoming subject matched to the field OTRS4ID, and the conversation is placed in the new ticket with this matching number keeping old tickets and new tickets together.

This use case is also applicable when moving part of your teams to a separate OTRS instance to keep systems more manageable.

Need more information or want help leaving your older ((OTRS)) Community Edition for a bright new shiny OTRS, shoot us a message at sales@otrs.com.

Thanks for reading!

((enjoy))

Your Truly,

///shawn

“The great pleasure in life is doing what people say you cannot do.”,

• 0